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A  data  abstraction  is  a  collection  of  sets  together 
with  a  collection  of  operations.  Methods  exist  for 
specifying  and  for  implementing  data  abstractions.  The 
central  question  for  any  particular  example  is  whether  the 
semantics  of  each  of  these  two  methods  corresponds  with  the 
intended  abstraction. 

An  algebraic  comparison  of  data  abstraction 
specifications  and  implementations  is  presented.  It  is 
shown  that  the  specified  and  implemented  abstractions  always 
overlap  and  have  a  common  (lattice)  structure  that  is 
valuable  in  understanding  the  modification  of  code  and 
specification. 


'7* A  new  specification  technique,  table  specification,  is 

^  v- 

proposed  that  emphasizes  the  underlying  congruence-class 
structure  of  data  abstractions.  Algorithms  to  transform 
tables  are  defined. 
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Introduc  tion 


Software  maintenance  is  a  process  of  changing  existing 
Implementations  to  meet  new  specifications.  It  is  often 
easy  to  change  a  specification,  but  difficult  to  make  the 
corresponding  change  to  its  implementation.  In  this  thesis 
we  examine  a  cause  for  this  difficulty  in  the  domain  of  data 
abstractions. 

A  method  for  specifying  data  abstractions,  called  the 
algebraic  or  axiomatic  specification  technique  has  been 
proposed  by  ]Zilles  74],  [Guttag  75]  and  ]ADJ  75b].  In  this 
method  data  abstractions  are  modeled  by  heterogeneous 
algebras.  We  show  that  these  algebras  have  a  lattice 
structure  that  is  shared  by  models  of  implementations  that 
share  the  same  syntax. 

Each  algebra  has  an  inner  structure,  congruence 
classes,  that  is  useful  in  studying  changes  to 
specifications  and  implementations.  A  new  method  of 
specification,  table  specification,  is  proposed  which 
emphasizes  this  inner  structure. 

Chapter  2  introduces  the  domain  of  interest,  data 
abstractions.  Distinctions  and  relationships  between  data 
abstractions,  specifications,  and  Implementations  are 


*£  IWiHr'  *  *«-*!*£. 


Introduced.  Chapter  3  reviews  some  algebraic  concepts  and 
presents  some  properties  of  the  structure  of  word  algebras. 
The  word  algebra  structure  is  used  in  Chapters  4  through  6 
to  examine  specifications  and  implementations.  Table 
specifications  and  their  transformations  are  covered  in 
Chapters  7  through  9. 
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2.  Data  Abstractions 


DEFINITION  2.1-  A  data  abstraction  i s  a 
collection  of  sets  with  a  collection  of  operations 
on  those  sets.  Each  set  in  a  data  abstraction  is 
called  a  domain  or  a  data  ty pe .  *** 

Several  programming  languages  provide  facilities  for 
defining  data  abstractions  as  program  objects 
[Dahl  et  al.  70],  [Liskov  et  al.  77], 

[Wulf,  London  &  Shaw  76],  [Gannon  &  Rosenberg  79].  A  class 
is  a  program  object  that  may  be  viewed  as  a  data 
abstraction.  The  correspondence  between  classes  and  data 
abstractions  is  described  by  an  interpretation,  a  mapping  of 
program  objects  and  operations  onto  abstract  objects  and 
o  pe  ra  t i ons . 

As  we  will  show  in  Chapter  5,  for  each  class  there  is 
at  least  one  corresponding  data  abstraction.  There  may  be 
one  abstraction  that  best  captures  the  intentions  of  the 
programmer,  the  creator  of  the  class.  This  does  not  rule 
out  the  existence  of  other  abstractions,  to  which  the  class 
corresponds  tinder  other  interpretations.  A  class  describes 
a  collection  of  data  abstractions  in  the  sense  that  some, 
but  not  all  data  abstractions  may  be  interpretations  of  the 


class 
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Another  way  to  describe  a  collection  of  data 
abstractions  is  by  a  specification.  In  particular,  we  will 
be  concerned  with  algebraic  specifications .  An  algebraic 
specification  has  syntax  that  must  obey  certain  restrictions 
in  order  to  be  well-formed.  Every  well-formed  algebraic 
specification  corresponds  to  at  least  one  data  abstraction, 
by  means  of  an  interpretation  of  the  symbols  in  the 
specification  onto  the  objects  and  operations  of  the  data 
abstraction.  As  with  classes,  there  may  be  one  data 
abstraction  that  best  captures  the  intentions  of  the 
specifier,  the  creator  of  the  specification,  but  there  may 
be  other  data  abstractions  to  which  the  specification 
corresponds. 

Because  classes  and  specifications  both  describe  data 
abstractions,  it  is  possible  to  compare  them  to  one  another. 
In  particular,  a  given  class  and  a  given  specification  may 
describe  the  same  collection  of  data  abstractions.  The 
intersection  of  these  collections  is  a  measure  of  the 
correspondence  between  the  class  and  the  specification. 
Similarly,  one  may  make  the  same  type  of  comparison  between 
two  specifications  or  between  two  classes. 

The  algebraic  structure  of  a  data  abstraction  may  be 
used  to  partition  each  set  in  the  abstraction  into  blocks. 
These  blocks  will  be  used  to  explain  similarities  between 
different  specifications  and  classes. 


***•« 
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3.  Word  Algebra 

By  reserving  the  term  data  abstraction  for  abstract, 
intuitive  objects  we  avoid  confusing  it  with  another  idea: 
the  syntax  of  a  class  or  a  specification.  In  other  words, 
the  meaning  of  a  class  or  a  specification  is  a  data 
abstraction.  In  any  particular  case,  a  data  abstraction 
arises  from  the  syntax  of  a  class  or  a  specification. 
However,  we  can  also  study  data  abstractions  apart  from 
their  defining  classes  or  specifications. 

Collections  of  sets  and  operations  on  those  sets  may  be 
described  by  a  mathematical  formalism:  heterogeneous 
(many-sorted)  algebra.  In  fact,  common  abstract  algebra 
suffices  to  describe  most  phenomena.  The  only  need  for 
heterogeneous  algebra  is  to  extend  concepts  to  objects  with 
more  than  one  set.  Because  the  number  of  sets  is  always 
finite,  these  extensions  are  straightforward. 


‘W 
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3.1.  Algebras 

DEFINITION  3.1  -  An  algebra  is  a  pair  ( D , M)  , 
where  D  is  a  collection  of  domains  and  M  is  a 
collection  of  mappings  from  cross-products  of  sets 
in  D  to  sets  in  D  .  When  the  operations  are 
understood  from  context,  we  omit  M  .  *** 

For  example,  the  natural  numbers  may  be  described  as  an 
algebra  with  one  domain,  the  set  of  natural  numbers,  and  two 
operations.  Zero  and  Successor  .  An  example  with  more 
than  one  domain  is  the  ubiquitous  stack..  Two  domains, 
natural  numbers  and  stacks,  are  needed.  The  usual 
operations  are  Newstack  ,  Push  ,  Pop  ,  Top  ,  and  the 
natural  number  operations. 

It  is  clear  that  names  are  needed  to  describe  the  sets 
and  operations,  but  that  names  are  not  enough.  Two  algebras 
may  have  the  same  names,  but  the  operations  may  do  different 
things.  Still,  the  two  algebras  have  something  in  common. 

We  capture  this  syntactic  idea  by  the  term  signature. 


7 


DEF IN  IT  ION  3.2  -  A  signature  is  a  triple 
(S,F,V)  ,  where  S  is  a  finite,  nonempty  set  of 
set  names,  called  types ;  F  is  a  finite,  nonempty 
set  of  function  names  and  their  arlties:  the  names 
of  the  types  that  make  up  their  domains  and 
ranges;  and  V  is  a  finite  set  of  variables  V.  . 

When  V  is  empty  we  omit  it  from  the  signature. 

For  each  function  f:  S,  x  ...  x  S  - >  S.  the 

product  set  x  ...  x  Sn  ,  sometimes  written 

(S^  ,  ...  ,  Sn)  ,  is  its  domain  a r i ty .  For 

constants  f:  - >  Si  ,  the  empty  tuple  (  )  is 

used  to  denote  the  empty  domain  arity.  Each 
variable  has  a  type ,  an  element  from  S  . 

The  domain  of  a  variable,  written  d  om  ( )  ,  is  a 
particular  subset  of  its  type.  Every  algebra  has 
a  signature.  Two  algebras  with  the  same  signature 
are  similar  algebras .  *** 

DEF IN  IT  ION  3.3  -  The  order  of  a  signature  is  the 
maximum  of  the  number  of  arguments  of  each 
function  in  the  signature.  The  T-o rd e r  of  a 
signature  is  the  maximum  of  the  number  of 
arguments  of  type  T  of  each  function  in  the 
signature.  *** 

It  is  often  useful  to  build  up  a  data  abstraction  from 


m—.  *»■■■■.> 


its  components.  Each  type  in  the  signature  is  specified 
(implemented)  separately,  in  a  sequence  of  specifications 
(classes).  Types  that  have  been  specified  (implemented) 
earlier  in  the  sequence  may  be  referenced  in  the  new 
specification  (class). 

DEFIN IT  ION  3.4  -  a  hierarchical  signature  is  a 
signature  whose  domains  and  functions  are  divided 
into  two  classes:  old  and  new.  Only  one  new 
domain  is  allowed,  called  the  type-of-interest,  or 
TO  1 .  *** 

DEFIN IT  ION  3.5-  A  hierarchical  specif ication 
(respectively,  class)  is  a  sequence  of 
specifications  (classes)  with  hierarchical 
signatures,  in  which  each  old  domain  or  function 
in  any  specification  (class)  is  a  new  domain  or 
function  in  some  previous  specification  (class)  in 
the  sequence.  *** 

The  hierarchical  signatures  of  the  natural  numbers  and 
stack  are  shown  in  Figures  3-1  and  3-2. 


Types 


Natural 


Func  cions : 


Figure  3-1 . 


Zero:  — >  Natural 

Succ:  Natural  -->  Natural 


Signature  of  natural  numbers 


Types: 


; 

Functions: 


Nat  (Old) 
S  tack 


Zero:  -->  Nat  (Old) 
Succ:  Nat  -->  Nat  (Old) 


Newstack:  — >  Stack 
Push:  Nat  x  Stack  — >  Stack 
Pop:  Stack  — >  Stack 
Top:  Stack  -->  Nat 


Figure  3-2.  Signature  of  Stack 


Two  signatures  are  the  same  if  and  only  if  the  names  of  the 
sets  and  operations  are  the  same  and  the  operations  have  the 
same  arities.  On  the  other  hand,  assigning  new  names  (e.g. 
changing  each  name  "abc"  to  "abc2”)  consistently  to  one  of 
the  signatures  does  not  change  the  fact  that  the  two 
signatures  describe  the  same  structure.  We  will  ignore  such 
distinctions  between  signatures  and  treat  two  signatures  as 
if  they  were  the  same  if  the  only  difference  between  them  is 
such  a  renaming. 

Implicit  in  this  discussion  of  signatures  is  the  notion 
of  possible  algebras  they  describe.  In  general,  a  signature 
may  be  shared  by  many  different  algebras.  However,  there  is 
a  natural  unique  algebra  for  each  signature.  If  each 
operation  produced  values  in  its  range  that  were  different 
from  all  the  values  produced  by  all  the  other  operations, 
and  if  a  new  value  was  produced  for  each  new  set  of  input 
values,  then  this  algebra  would  be  the  most  "general" 
algebra  for  that  signature.  That  is,  it  would  have  as  many 
distinct  values  as  possible.  Note  that  this  definition 
allows  the  domains  to  contain  values  that  are  not  in  the 
ranges  of  any  operations.  We  dispense  with  such  values  by 
t  he  f o 1 lowi ng : 

CON  VENT  ION  3.6  -  The  elements  of  domains  of  an 

algebra  are  restricted  to  those  values  that  are 

results  of  operations  in  the  algebra. 
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This  is  an  intuitive  restriction  for  program  objects. 
The  only  values  that  can  exist  are  those  that  arise  from 
operations.  (We  treat  initialization  as  a  constant 
operation.)  We  now  have  a  unique  algebra  to  associate  with 
each  signature,  the  cons  tant  word  algebra. 

DEFINITION  3.7  -  The  word  algebra  W  (S,F,V)  of 
a  signature  (S,F,V)  is  the  set  of  all  words 
formed  as  follows: 

(1)  For  each  function  f:  --->  ,  the  symbol 

”  f  "  is  a  word  of  type  . 

(2)  Each  variable  symbol  with  domain  is 

a  word  of  type  . 


(3)  If 

f : 

S ,  x  ...  x  S„  -« 
1  n 

— >  si 

is  a  function 

in 

F 

a  nd  w  |  ,  ...  , 

w  are 

n 

words  of  types 

S1 

»  • 

..  ,  Sn  ,  then 

f  » 

• • •  »  wn)  is  a 

wo  rd 

of 

type  S.  . 

A  word  containing  no  variable  symbols  is  called  a 
constant.  The  constant  word  algebra  W  (S,F,V) 
is  the  set  of  all  constants  in  W  (S,F,V)  .  *** 

For  example,  the  constant  word  algebra  of  the  signature 
of  the  natural  numbers  contains  constants: 

Zero 

Succ(Zero) 

Succ(Succ( Ze ro)  )  ,  etc. 

The  constant  word  algebra  of  the  stack  signature  contains 


i 


such  constants  of  type  Stack  as; 

News  tack 

Push(Newstack,Zero) 

Pop(Push(Newstack , Zero) )  ,  etc. 

The  same  algebra  contains  constants  of  type  Nat  : 
Ze  ro 

Succ( Ze  ro) 

Top( Push(News tack , Ze ro) )  ,  etc. 


DEFINITION  3.8  -  Let  <S,F,V)  be  a  signature. 

An  instance  w'  of  a  word  w  €  W  (S,F,V)  is  an 
element  of  Wc(S,F,V)  obtained  by  consistently 
substituting  constants  for  variables  in  w  .  An 
instance  (  Wj '  ,  ...  ,  wn'  )  of  an  n-tuple 

(  w j  ,  ...  i  wn  )  is  obtained  by  using  the  same 
substitution  scheme  for  variables  in  each  word 

u  u 

w  l  >  •  •  •  *  wn  • 


As  a  special  case  of  the  definition,  for  each  variable 
of  type  T^  in  a  signature  (S,F,V)  ,  the  set  of  all 

instances  of  V  ^  is  the  set  of  all  constants  of  type  T  ^ 
in  Wc(S,F,V)  . 
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3.2.  Semantic  Interpretations 

As  can  be  seen  in  the  stack  example,  the  constant  word 
algebra  may  contain  more  distinct  values  than  intended.  In 
particular,  Newstack  and  Po p ( Push(N ews tack  ,  Ze ro) )  are 
probably  intended  to  be  the  same  value.  We  can  accomplish 
this  by  defining  equivalence  relations  on  the  domains. 

DEFIN IT  ION  3.9  -  An  equivalence  relation  over 

a  set  S  is  a  binary  relation  satisfying  the 
following  properties,  for  all  x  ,  y  and  z  in 
S  : 


(1) 

X 

/v 

X 

.  (Reflexive) 

(2) 

If 

X 

/V 

y  then  y  ***  x  .  (Symmetric) 

(3) 

If 

X 

/V 

y  and  y  S*  z  then  x  ^  z  . 

(T  ransitive) 

The  subset  of  S  of  all  elements  equivalent  to 
x  ,  called  the  equivalence  class  o f  x  ,  is 
denoted  by  \x\  .  *** 

The  first  two  laws  of  equivalence  relations  are 
obviously  needed  for  any  relation  that  is  meant  to  capture 
equality.  Transitivity  ensures  that  if  two  values  are 
equal,  it  does  not  matter  how  they  were  produced.  For 
example,  if  Po p ( Push(N ews tack , Ze ro ) )  is  equal  to 
Newstack  ,  and  ( Po p ( Push(N ews tack  ,  Sue c ( Ze ro)  )  )  is  equal 
to  Newstack,  then  Po p ( Push(N ews tack  ,  Ze ro )  )  is  equal  to 


Pop(Push(Newstack,Succ(Zero)  )) 
of  a  value  does  not  matter. 


1  5 


The  history  of  production 


It  would  not  be  correct  to  allow  any  set  of  equivalence 
relations  on  domains  to  define  equality  of  values.  The 
relations  on  each  domain  must  be  consistent  with  one 
another.  Further,  if  two  values  are  equal,  then  they  should 
yield  equal  results  when  passed  as  parameters  to  the  same 
operation.  These  two  properties  are  captured  by  the 
following  definition. 


DEFIN IT  ION  3.10  -  A  congruence  on  an  algebra 
( D , M)  is  a  set  of  equivalence  relations, 

one  relation  defined  on  each  set  £  D  ,  with 

the  substitution  property: 

(4)  For  all  functions  f:  D,  x  ...  x  D  - >  D 

1  n  m 


x^  y ^  ,  where  i 

implies 


9  *99  9 


,  ...  ,  xn) 


'm  fCyl 


>  y„> 


|x|  denotes  the  congruence  class  o f  x  . 


*** 


For  example,  in  a  congruence  on  stack, 

Ze  ro  ■  Sue  c(Zero) 
lm  pi  1  e  s 

Push(News tack , Ze ro)  ■  Pus h( N ews tack , Sue c ( Ze ro ) )  . 


Fur  thermo  re , 
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Zero  ■  Succ(Zero) 
implies 

Succ(Zero)  *  Succ(Succ( Zero) )  *  ... 

Unfortunately,  defining  a  congruence  on  an  algebra  does 
not  change  the  number  of  elements  in  the  domains  of  the 
algebra.  Po p( Push(N ews t ack  ,  Ze ro )  )  and  Newstack  may  be 

in  the  same  congruence  class,  but  they  are  still  different 
words.  What  we  want  is  another  algebra  with  one  object  for 
each  class  of  equal  words  according  to  a  congruence  defined 
on  Wc  .  Such  an  algebra  is  uniquely  defined  for  each 
c  ong  ruence . 

DEFINITION  3.11-  A  quotient  algebra  (D/C,M)  is 
the  algebra  formed  from  (D,M)  by  substituting  a 
congruence  class  of  for  each  set  of  elements 

equal  under  in  each  set  .  For  each 

function  f:  -->  D2  in  the  original  algebra 

( D , M)  ,  the  new  function  f':  Dj/Cj  — >  D2/C2  is 
defined  in  the  natural  way:  f'([x[)  =  |f(x)^ 

Where  there  is  no  confusion  we  reuse  the  old  names 
for  the  new  functions  and  drop  the  class  brackets, 
writing  f(x)  for  f ' ( J  x \ )  and  x  for  |x|  . 

■k  *  * 

Suppose,  for  example,  that  we  defined  a  congruence  on 

1  2 

the  natural  numbers  by:  Zero  -  Succ  (Zero)  ,  where 
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fn(x)  is  an  abbreviation  for  tf  (f  ( .  .  .  f  (x)  .  .  .  )  )  . 

Note  that  several  other  equalities  are  implied,  such  as: 

1  3 

Succ(Zero)  ■  Succ  (Zero)  . 

It  can  be  shown  that  there  are  only  twelve  classes  of 

values,  where  all  the  values  in  each  class  are  equal  to  one 

another.  If  we  call  this  congruence  mod  1 2  ,  then  we  can 

define  a  quotient  algebra  ( ^Na t$ /modi  2 ,  £zero,Succ$)  .  The 

quotient  algebra  has  one  domain  with  twelve  different  values 

in  it.  The  value  produced  by  Succ(Zero)  is  the  same  value 

1  3 

as  produced  by  Succ  (Zero)  . 

Because  every  quotient  algebra  arises  from  some  larger 
algebra  by  means  of  a  congruence,  there  is  a  natural  mapping 
between  the  two  algebras.  For  every  value  in  the  large 
algebra  there  is  a  corresponding  value  in  the  quotient 
algebra  that  "behaves"  in  the  same  way  with  respect  to  the 
operations  of  the  algebras.  Every  value  in  the  quotient 
algebra  corresponds  to  some  value  or  set  of  values  in  the 
large  algebra.  This  relationship  is  described  by  an 
epimorphism  from  the  large  algebra  to  the  quotient  algebra. 


1  8 


DEFIN IT  ION  3.12  -  An  algebra  homomorphism ,  or 

just  a  homomorphism  h:  (D,M)  - >  (D',M')  is  a 

mapping  between  similar  algebras  (i.e.,  they  have 
the  same  signature)  that  preserves  the  functions: 

h(f(w1  ,  ...  ,  wn))  -  f  ( h  ( Wj  ) . h(wn)) 

for  all  elements  w.  of  D  and  all  functions  f 
in  M  .  An  epimorphism  is  an  onto  homomorphism. 

*  *  * 

We  state  without  proof  a  theorem  of  [Birkhoff  &  Lipson  70]: 

THEOREM  3.13  -  The  set  of  all  epimorphisms  of  an 
algebra  A  is  completely  determined  by  the  set  of 
all  quotient  algebras  of  A  .  *** 

Given  a  class  or  a  specification,  we  can  generate  the 
constant  word  algebra  of  its  signature.  In  general,  Wc 
will  be  too  large:  the  number  of  values  intended  will  be 

smaller  than  the  number  of  values  in  W  W  cannot  be 

c  c 

too  small,  given  Convention  3.6  for  algebras.  The  intended 
algebra  of  a  class  or  specification,  then,  must  be  some 
quotient  algebra  of  W^  .  We  call  an  intended  algebra,  a 
semantic  interpretation. 

DEFIN IT  ION  3.14  -  A  semantic  interpretation  of  a 


class  or  a  specification  is  an  epimorphism  of  the 
constant  word  algebra  of  the  signature.  *** 


1  9 


3.3.  Lactices 

Just  as  every  quotient  algebra  is  related  to  its 
original  algebra  by  an  epimorphism,  some  of  the  quotient 
algebras  of  a  given  algebra  are  related  to  one  another  by 
epimorphisms .  For  example,  we  could  define  a  new  congruence 
mod4  on  the  natural  numbers  by  the  equation: 

Zero  »  Succ^(Zero)  . 

The  new  algebra,  (^Nat^/mod4,  ^Zero,  SuccJ)  ,  is  the 
epimorphic  image  of  the  algebra  modi 2  under  the  following 
mapping : 

4  8 

Zero,  Succ  (Zero),  Succ  (Zero)  -->  Zero 
5  9 

Succ(Zero),  Succ  (Zero),  Succ  (Zero)  -->  Succ(Zero) 


2 

Succ  (Zero)  , 

Sue  c^(Zero) , 

Succ^(Zero)  — > 

Sue  c^ 

(Zero) 

3 

Succ  (Zero), 

Sue  c^ (Zero), 

Succ  *  1  ( Ze  ro)  --> 

Sue  c^ 

(Zero)  . 

On  the  other  hand,  the  algebra  mod!3  defined 

by : 

1  3 

Zero  =  Succ  (Zero) 

is  not  related  to  either  mod4  or  mod  1 2  .  Such 
relationships  are  described  by  partially  ordered  sets . 
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DEF IN  IT  ION  3.15  -  A  partially  ordered  set,  or 
poset,  (X,<“)  is  a  set  X  with  a  relation  <■ 
satisfying  the  following  properties,  for  all  x  , 
y  ,  z  in  X  : 

(1)  x  <•  x  .  (Reflexive) 

(2)  x  <-  y  and  y  <»  x 

implies  x  ■  y  .  (Antisymmetric) 

(3)  x  <-  y  and  y  <■  z 

implies  x  <-  z  .  (Transitive) 

*  ** 

A  relation  A  <-  B  on  quotient  algebras  is  always 
defined  by  the  existence  of  an  epimorphism  from  B  to  A  . 
The  congruence  classes  of  the  domain  algebra  B  are 
contained  (in  the  set-theoretic  sense)  in  the  congruence 
classes  of  the  range  algebra  A  .  For  example,  the  classes 
of  mod  1 2  are  contained  in  the  classes  of  mod4  . 

Some  posets  are  closed.  That  is,  there  exists  a  value 
in  the  poset  that  is  smaller  than  every  value,  and  there 
exists  a  value  in  the  poset  that  is  larger  than  every  other 
value.  When  this  happens,  the  poset  is  called  a  complete 


Lattice. 
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DEFINITION  3.16  -  A  lattice  is  a  partially 
ordered  set  in  which  every  two  elements  have  a 
least  upper  bound,  called  the  join,  and  a  greatest 
lower  bound,  called  the  meet ,  in  the  set.  A 
complete  lattice  L  is  a  lattice  in  which  every 
subset  of  L  has  a  join  and  a  meet  in  L  .  A 
sublattice  is  a  subset  L  of  a  lattice  M  closed 
under  the  join  and  meet  operations  of  M  , 
operating  on  subsets  of  L  .  A  lower  semilat  tice 
is  a  partially  ordered  set  in  which  every  two 
elements  have  a  meet.  *** 

The  quotient  algebras  of  Wc  are  closed  under  the 
ordering  defined  above,  containment  of  congruence  classes, 
because  is  smaller  (under  the  defined  ordering)  than 

every  quotient  algebra,  and  the  trivial  algebra,  which  has 
one  value  in  each  domain,  is  larger  than  every  other 
quotient  algebra.  In  fact,  for  all  heterogeneous  algebras 
we  have  the  following  theorem  of  [Birkhoff  &  Lipson  70]: 

THEOREM  3.17  -  The  poset  of  all  congruences  on  an 
algebra  forms  a  complete  lattice.  *** 

And,  in  particular,  we  have  the  following  corollary: 
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CO  ROLLARY  3.18  -  The  collection  of  semantic 
interpretations  of  a  class  or  a  specification 
forms  a  complete  lattice,  denoted  by  Ly  .  *** 

As  an  example,  part  of  the  lattice  of  semantic 
interpretations  of  the  natural  numbers  signature  is  given  in 
Figure  3-3.  Each  box  in  the  Figure  represents  a  quotient 
algebra  defined  by  the  congruence  described  by  the  equation 
in  the  box.  The  entire  lattice  is  infinite:  there  are  an 
infinite  number  of  quotient  algebras  for  that  signature.  In 
fact,  there  are  an  infinite  number  of  quotient  algebras  just 
below  the  trivial  algebra:  one  for  each  prime  number. 
Similarly,  there  are  an  infinite  number  of  levels  in  the 
lattice:  there  are  numbers  that  have  an  infinite  number  of 
powers  of  two,  say.  Nevertheless,  there  is  one  unique 
algebra  at  the  very  bottom  of  the  lattice:  the  natural 
numbers.  Every  other  algebra  equates  at  least  two  words. 


i 
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4.  Specifications 


The  purpose  of  this  section  is  to  relate  algebraic 
s pec i f icat ions ,  syntactic  objects,  to  semantic 
interpretations,  semantic  objects.  The  particular  type  of 
specifications  considered  here  are  essentially  those  of 
[Guttag  75],  but  without  conditional  axioms. 
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4.1.  Algebraic  Specif icacions 

DEFINITION  4.1  -  An  algebraic  specification 
consists  of: 

(1)  A  signature  (S,F,V)  . 

(2)  A  finite  collection  of  axioms :  pairs  of  words 
of  the  same  type  from  W  (S,F,V)  ,  the  two 
members  of  each  pair  separated  by  "  *  ". 

Note  that  there  may  be  an  empty  collection  of 
axioms.  *** 

Figures  4-1  and  4-2  contain  specifications  of  Natl2 
and  Stack  ,  two  data  abstractions  discussed  in  the  previous 
chapter. 


Functions:  Zero:  — >  Nat 

Sue  c :  Nat  — >  Nat 

Axioms:  Succ12(Zero)  -  Zero 


Figure  4-1.  Specification  of 


Na  1 1  2 


Types:  Nat  (old) 

Stack 


Functions:  Zero:  — >  Nat  (Old) 

Sue c :  Nat  -->  Nat  (Old) 

Newstack:  -->  Stack 
Push:  Nat  x  Stack  — >  Stack 
Pop:  Stack  — >  Stack 
Top:  Stack  — >  Nat 


Variables:  N:  Nat 

S :  Stack 


1  2 

Axioms:  Succ  (Zero)  -  Zero  (Old) 

Pop(Push(N , S) )  -  S 
Top( Push(N , S)  )  -  N 
Pop(Newstack)  -  Newstack 
To p(N ews tack )  -  Zero 


Figure  4-2.  Specification  of  Stack 


4.2 


Correctness 


It  is  clear  that  the  lattice  of  semantic 

interpretations  contains  more  interpretations  than  are 

intended  by  the  specifications.  In  particular,  the  semantic 

interpretation  of  the  signature  of  Natl2  (Figure  4.1)  that 

corresponds  to  the  congruence  mod  1 3  (see  Section  3.3)  is 

in  conflict  with  the  axiom: 

1  2 

Zero  ■  Succ  (Zero)  . 

Axioms  are  intended  to  be  true  statements  about  the  objects 
described  by  the  specification.  To  make  this  notion  more 
precise,  we  define  the  collection  of  words  from  Wc  that 
may  be  derived  equal  by  a  specification. 
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DEFINITION  4.2  -  A  derivation  from  a 

specification  S  is  a  finite  sequence  of 

equations  which  may  be  formed  as  follows: 

(1)  w  ■  w  ,  where  w  is  any  constant  of  Wc  , 

Is  an  equation. 

(2)  If  Wj  »  w^  is  an  equation  then 

w2  *  W1  1 8  an  e9uat*on* 

(3)  If  Wj  •  w^  and  *  w^  are  equations, 

then  w ^  -  w^  is  an  equation. 

(4)  An  equation  is  formed  from  an  axiom  of  S  by 
an  assignment  of  constants  to  variables, 
where  each  occurrence  of  a  variable  x  of 
type  D  is  consistently  replaced  by  a 
constant  w  of  type  D  . 

(5)  If  Wj  -  W£  and 

f ( • • •  ,  c  ,  ...)  *  f  C .  .  .  i  c  ,  . . . )  are 

equations,  and  the  constant  c  is  of  the 
same  type  as  w^  and  w2  ,  then 
^ ■  t  ^  j  ,  ...)  *  f (  .  .  .  ,  v  2  i  * . . )  is 
an  equation. 

The  last  equation  in  a  derivation  is  the  equation 

derived.  *  ** 

For  example,  Figure  4-3  contains  some  derivations  from 


the  sperifi'-ation  of  Natl2  in  Figure  4-1. 
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1  3 

(a)  Derivation  of  Succ  (Zero)  ■  Succ(Zero) 

Equation  Rule 

1  2 

Succ  (Zero)  «  Zero  (4) 

1  3 

Succ  (Zero)  -  Succ(Zero)  (5) 

1  2 

(b)  Derivation  of  Zero  -  Succ  (Zero) 

Equat ion  Rule 

1  2 

Succ  (Zero)  *  Zero  (4) 

Zero  -  Succ^(Zero)  (2) 

2  4 

(c)  Derivation  of  Succ  (Zero)  -  Zero 

Equation  Rule 

1  2 

Succ  (Zero)  -  Zero  (4) 

Succ^(Zero)  *  Succ^(Zero)  (5) 

Succ^(Zero)  -  Zero  (3) 


Figure  4-3.  Examples  of  derivations 

L 
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The  collection  of  all  derivations  forms  a  relation  on  the 
constant  word  algebra. 

DEFINITION  4.3  -  Two  elements,  w^  and  w^  ,  of 
the  constant  word  algebra  Wc  of  a  specification 
S  are  in  the  relation  speceq  if  and  only  if 
the  equation  can  be  derived  from  S  . 

We  say  that  w^  and  W2  are  equal  in  speceq  . 

*  ** 

Because  derivations  obey  reflexivity,  symmetry, 
transitivity  and  subs t i tut ivi ty ,  we  have  the  following 
result. 

LEMMA  4.4  -  Speceq  is  a  congruence  on  Wc  . 

*  ** 

PROP F  -  By  rule  (1)  speceq  is  reflexive.  By 
rule  (2)  it  is  symmetric.  By  rule  (3)  it  is 
transitive.  So,  speceq  is  an  equivalence 
relation.  To  show  that  it  is  a  congruence  we  must 
demonstrate  s ub s t i t ut iv i t y .  Let  w^  and  be 

equal  constants  of  type  S'  in  speceq  .  Then  by 
definition  there  is  a  derivation  D  of  wi  “  w2  ’ 
For  each  function: 

f •  S.  x  ...  x  S  x  ...  x  S  - S . 


construct  a  derivation  D'  of: 
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f(Cj  ,  ...  ,  c '  ,  ...  ,  cn)  - 

f(Cj  ,  ...  ,  c'  ,  ...  ,  cn)  . 

This  is  always  possible  for  nonempty  domains 
S  j  ,  ...  ,  Sn  ,  S'  ,  by  rules  (1)  and  (5). 

Appending  D'  to  D  ,  we  can  derive: 
f (Cj  ,  ...»  Wj  .....  cn)  = 

f ( c 1  *  *  *  *  *  w2  *  *  * •  ’  c n ^ 

by  rule  (5).  *** 

DEFIN IT  ION  4.5  -  The  quotient  algebra  s  pecalg 
of  a  specification  (D,M)  is  defined  by  the 
congruence  speceq  of  S  : 

specalg  3  (W  (D , M) /speceq ,M)  .  *** 

One  way  of  looking  at  specifications  is  to  view  them  as 
describing  models .  That  is,  an  algebra  in  which  all  the 


axioms  are  true  is  a  model  of  that  specification. 


DEFINITION  4.6  -  Let  S  be  a  specification  with 
signature  (T,F,V)  .  Let  A  be  an  algebra  with 

t 

the  same  signature.  Define  the  extension  A'  of 
A  as  follows: 

(1)  Add  a  special  type  BOOL  with  constant 
functions  TRUE:  -->  BOOL  and 

FALSE:  — >  BOOL  .  (This  new  type  Is  not  to 
be  confused  with  any  other  type  Bool 
already  in  A  .  If  necessary,  the  old  type 
Bool  is  renamed  so  as  not  to  conflict  with 
the  new  type  BOOL  .) 

(2)  For  each  type  T^  in  T  add  a  function 

TiEQ:  Ti  x  Tt  -->  BOOL  . 

Tj^EQCw^,  w 2)  *  TRUE  if  and  only  if  and 

w 2  are  the  same  constant  of  type  T ^  in 
WC(T,F,V)  .  Otherwise, 

TiEQ(w1,  w  2 )  =  FALSE  . 

An  axiom  wi  ”  w2  ^  »  where  w^  and  w^  are 

words  of  type  T^  ,  is  true  if  and  only  if  every 
instance  (w^',  w^ ' )  of  (w^,  w2)  yields 
T^EQ(Wj',  w2 ' )  ■  TRUE  in  A'  .  A  is  a  model 
for  S  if  and  only  if  every  axiom  in  A  is  true. 
We  say  that  A  is  correc  tly  specified  by  S 
whenever  A  is  a  model  for  S  .  *** 
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LEMMA  4.7  -  Given  a  specification  S  ,  its 
quotient  algebra  specalg  is  correctly  specified 
by  S  .  *** 

PROOF  -  Let  =*  w  be  any  axiom  in  S  .  By 

derivation  rule  (4),  any  instance  w^ *  -  '  > 

where  all  variables  have  been  consistently 
replaced  by  constants,  may  be  derived.  Therefore, 
every  axiom  is  true  in  specalg  .  *** 

In  a  sense,  specalg  is  the  "best"  model  of  a 
specification,  because  it  contains  as  many  different  values 
in  each  domain  as  allowed  by  the  axioms.  However,  it  is 
not,  in  general,  the  only  quotient  algebra  of  the  constant 
word  algebra  that  is  a  model  of  a  given  specification.  For 
example,  Nat4  =  (£Nat*^/mod4,  ^Zero.Succ^)  is  a  model  of 

Nat  12  (Figure  4-1),  because  the  axiom: 

1  2 

Zero  -  Succ  (Zero) 

is  true  in  Nat4  .  It  is  easy  to  describe  the  collection  of 
models  of  a  specification. 

DEF IN  IT  ION  4.8  -  A  quotient  algebra  is  said  to 
satisfy  a  specification  if  and  only  if  it  is  the 
epimorphic  Image  of  specalg  of  that 


specification. 


*  *  * 


THEOREM  4.9  -  A  data  abstraction  A  is  correctly 
specified  by  a  specification  S  if  and  only  if 
A  satisfies  S  .  *** 

PROOF  - 

(  Satisfy  S  «■■>  Correct  ) 

Let  h:  specalg  - >  A  be  an  epimorphism. 

Then,  for  every  equation  w^  *  true  in 

specalg  we  have  h(w^)  »  h(w2)  true  in  A  .  In 
particular,  the  image  of  every  instance  of  every 
axiom  in  S  Is  true  in  A  ,  because  they  are  true 
in  specalg  .  So,  A  is  a  model  for  S  . 

(  Correct  ■■■>  Satisfy  S  ) 

Let  jwi{  denote  the  congruence  class  of 
w^  in  specalg  ,  |w^  denote  the  set  of  all 

words  that  are  equal  to  w^  in  A  .  We  show  that 
JwJ  *5  |wi\  for  all  i.  Let  E  bean 
equation  in  a  derivation  of  wi  "  w2  *  E  is 

a  consequence  of  any  of  rules  (1),  (2),  (3)  or  (5) 
it  must  be  true  in  A  .  If  E  is  a  consequence 
of  rule  (4),  then  it  follows  by  an  axiom  of  S  . 

But,  all  axioms  in  S  are  true  in  A  .  So,  E 
is  true.  Therefore,  wi  “  w2  *-n  A  •  *** 

The  axioms  are  treated  here  as  minimal,  but  not  maximal 
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conditions.  That  is,  a  specification  does  not  describe  a 
unique  object,  but  a  collection  of  objects,  all  of  which 
satisfy  the  axioms.  Fortunately,  the  collection  is  closed. 

THEOREM  4.10  -  The  collection  of  data 

abstractions  that  are  correctly  specified  by  a 

specification  form  a  complete  sublattice  of  . 

We  denote  the  sublattice  by  L  .  *** 

s 

PROP F  -  Let  S  be  the  set  of  all  correctly 
specified  data  abstractions.  Every  data 
abstraction  in  S  is  an  epimorphic  image  of 
specalg  .  So,  it  is  an  epimorphic  image  of  the 
constant  word  algebra,  and  is  in  Lw  .  The  meet 
and  join  operations  in  Lw  are  congruence 
class  intersection  and  congruence-closure 
union  .  We  must  show  that  S  is  closed  under 
these  operations.  Every  element  of  S  contains 
the  congruence  classes  of  specalg  in  its 
congruence  classes.  The  intersection  and 
congruence-closure  union  of  classes  will  contain 
the  congruence  classes  of  specalg  .  So,  S  is 
closed  under  meet  and  join  .  The  trivial 
algebra  is  the  top  element  of  Lg  .  Specalg  is 


the  bottom  element. 
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Figure  4-4  contains  the  lattice  of  data  abstractions, 
or  algebras,  that  are  correctly  specified  by  Natl2  .  Each 
box  in  the  Figure  represents  an  algebra.  The  equation  in 
the  box  is  an  axiom  that  must  be  true  in  that  algebra. 

There  are  only  six  data  abstractions  in  the  lattice. 
Comparing  this  lattice  to  Figure  3-3,  we  see  that  it  is  a 
sublattice  of  Lw  of  the  signature  (|Nat^,  ^Zero.Succ^ )  . 
Note  that  the  lines  connecting  boxes  represent  epimorphisms 
implied  by  transitivity.  The  data  abstraction  at  the  bottom 
of  the  lattice  is  specalg  .  The  data  abstraction  at  the 
top  is  the  trivial  algebra,  with  one  element  in  Nat  . 

The  data  abstraction  at  the  bottom  of  the  lattice  L 

s 

for  a  specification  is  the  initial  algebra  of  that 
specification,  in  the  terminology  of  [ADJ  77].  That  is, 
there  is  a  unique  homomorphism  from  specalg  to  every  other 
algebra  that  satisfies  the  axioms.  In  fact,  there  is  a 
unique  epimorphism  defined  by  the  lattice. 


4.3.  Inequalities 


3  9 


[Giarratana  et  al.  76]  and  [Polajnar  78]  describe 
similar  lattices,  but  without  allowing  as  many 
Interpretations.  In  particular,  the  trivial  algebra  is 
disallowed.  This  can  be  done  by  insisting  that  some  domains 
have  a  single,  allowed  interpretation  in  abstractions.  For 
example,  one  could  insist  that  the  natural  numbers  in  stack 
have  a  fixed  (perhaps  infinite)  number  of  elements.  To 
accomplish  this,  we  introduce  the  notion  of  inequalities  in 
specifications. 

DEFINITION  4.11-  An  algebraic  specification  with 
inequalities  consists  of: 

(1)  An  algebraic  specification 

(2)  A  collection  of  inequalities :  pairs  of 

well-formed  terms  composed  from  the  elements 
of  the  algebraic  specification  (function 
names  and  variables),  the  two  members  of  each 
pair  separated  by  ”  ". 

The  s lgnature  of  an  algebraic  specification  with 
inequalities  is  the  signature  of  (1).  If  all  the 
inequalities  are  composed  of  constant  terms  we 
call  the  specification  an  algebraic  specification 
with  constant  inequalities.  *** 

Note  that  the  set  of  inequalities  may  be  Infinite.  When  the 


sec  Is  empty  we  have  a  specification  as  defined  in  Section 
4.1. 

An  example  of  a  specification  with  inequalities  is 
shown  in  Figure  4-5.  It  is  clear  that  an  inequality  may 
imply  other  inequalities.  For  example: 

Zero  }  Succ^(Zero) 
implies  that 

3 

Zero  #  Succ  (Zero)  . 

However,  inequality  is  not  a  transitive  relation.  It  is  the 

transitivity  of  equality  combined  with  the  contradiction  of 

inequality  that  yields  the  implication.  That  is, 

3 

Zero  •  Succ  (Zero) 
implies,  by  transitivity, 

Zero  *  Succ^(Zero)  , 
which  is  contradicted  by 

Zero  i  Succ^(Zero)  . 

A  logical  way  to  proceed,  then,  is  to  treat  each  inequality 
as  potentially  contradicting  a  collection  of  equalities.  To 
find  the  collection,  we  find  the  collection  of  equal  word, 
derived  from  an  equality. 


es :  Na  t 


Functions:  Zero:  -->  Nat 

Succ:  Nat  -->  Nat 


Axioms:  Succ^(Zero)  *  Zero 


Inequalities:  Succ(Zero)  t  Zero 


Figure  4-5.  Specification  of  Natl2  with  inequalities 
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DEFINITION  4.12  -  Two  elements,  w^  and  ,  of 

the  constant  word  algebra  Wc  of  a  specification 
with  inequalities  S(I)  are  in  the  relation 
specineq(i)  if  and  only  if  the  equation 
w  ”  w2  can  be  derived  from  the  specification 

S'  ;  where  S'  is  formed  from  the  signature  of 
S  and  one  axiom:  the  axiom  that  equates  the  two 
terms  of  the  inequality  i  .  The  relation 
s  peceq  is  defined  to  be  the  same  as  for  the 
specification  without  inequalities.  *** 

We  can  form  a  quotient  algebra  from  specineq(i)  just  as  we 
did  from  speceq  . 

LEMMA  4.13  -  Specineq(i)  is  a  congruence  on 
Wc  ,  for  each  inequality  i  .  *** 

PROP F  -  Specineq(i)  is  the  congruence  relation 
speceq  for  the  specification  with  one  axiom,  the 
axiom  that  equates  the  two  sides  of  the  inequality 
i  . 


★  *  * 


DEFINITION  4.14  -  The  quotient  algebra 
spec lnalg ( i  )  of  a  specification  with 
inequalities  S(I)  is  defined  by  the  congruence 
specineq(i)  of  S  : 

specinalg(i)  •  Wc/ s pec ineq ( i  ) 
for  each  inequality  i  £  I  .  The  quotient 
algebra  s pecalg  is  defined  to  be  the  same  as  for 
the  specification  without  inequalities.  *** 

The  quotient  algebra  speclnalg(i)  is  in  contradiction  with 
the  inequality  i  .  That  is,  it  only  has  one  value  where 
the  inequality  states  that  there  are  two  different  values. 

Specinalg(i)  is  not  an  algebra  correctly  specified  by  the 
specification. 

DEF1NIT ION  4.15  -  A  quotient  algebra  is  said  to 
satisfy  a  specification  with  inequalities  S(I) 
if  and  only  if  (1)  it  i3  an  epimorphic  image  of 
specalg  and  (2)  it  is  not  an  epimorphic  image  of 
any  specinalg(i)  for  all  inequalities  i  €  I  . 

*** 

TH EO REM  4.16  -  A  data  abstraction  A  is 
correctly  specified  by  a  specification  with 
inequalities  S(I)  if  and  only  if  A  satisfies 
S(I)  .  *** 
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PROP  F  -  Every  axiom  in  S(I)  is  true  in  A  , 
because  A  is  an  epimorphio  image  of  specalg  . 

Every  inequality  i  in  I  is  true  in  A  , 
because  A  is  not  an  epimorphic  image  of 
specineq(i)  .  Thus,  A  is  a  model  for  S ( I  )  . 

If  A  is  a  model  for  S(I)  ,  then  the  axioms 
are  true,  and  the  inequalities  are  true.  So,  A 
satisfies  S(I)  .  *  *  * 

Adding  inequalities  to  a  specification,  then, 
potentially  removes  some  data  abstractions  from  the 
collection  that  satisfy  the  specification.  If  the  original 
collection  formed  a  lattice,  what  does  the  new  collection 
look  like? 

TH  EOREM  4.17  -  The  collection  of  data 

abstractions  that  are  correctly  specified  by  a 

specification  with  inequalities  S(I)  forms  a 

complete  lower  s  ub-s  em  i  1  a  1 1  i  c  e  of  if  and  only 

if  specalg  is  not  an  epimorphic  image  of  any 

specinalg(t)  ,  for  all  inequalities  i  £  I  . 

If  it  is,  the  collection  is  void.  We  denote  the 

semilattice  S  .  *  *  * 

s 

PROG  F  -  When  specalg  is  an  epimorphic  image  of 
some  speclnalg(i)  every  epimorphic  image  of 
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specalg  is  an  epimorphic  image  of 
specinalg(i)  ,  because  epimorphisms  compose. 

Hence,  there  is  no  model  for  S(I)  in  this  case. 
Otherwise,  the  collection  of  correctly  specified 
data  abstractions  is  closed  at  the  bottom  by 
specalg  .  *** 

Figure  4-6  contains  the  semilattice  of  data 
abstractions  that  satisfy  the  specification  in  Figure  4-5. 

By  adding  the  inequality: 

Zero  i  Succ^(Zero) 

the  semilattice  may  be  reduced  to  a  single  abstraction. 

If  a  specification  contains  at  least  one  axiom  it  is 
possible  to  delete  the  whole  lattice  by  one  inequality:  the 
inequality  of  any  substitution  instance  of  the  two  words  in 

the  axiom.  For  example, 

1  2 

Zero  i4  Succ  (Zero) 

reduces  Natl2  to  nothing:  there  are  no  data  abstractions 
that  satisfy  the  specification.  Notice  that  any  inequality 
that  defines  (by  changing  the  inequality  into  an  equality)  a 
quotient  algebra  of  which  specineq  is  an  epimorphic  image, 
reduces  the  lattice  to  nothing.  If  no  one  inequality  in  a 
collection  (possibly  infinite)  reduces  the  lattice  to 
nothing,  then  the  whole  collection  does  not. 


The  final  algebra  of  [Wand  79]  and  (Kamin  79]  is  the 
top  element  of  Sg  which  is  guaranteed  to  be  a  lattice  by 
choosing  a  particular  subalgebra  for  all  domains  except  the 
type-of-interest.  That  is,  an  interpretation  is  chosen  for 
each  of  the  base  types  of  the  language.  Usually,  this 
interpretation  is  described  by  the  initial  algebra  of  a 
specification.  (E.g.,  there  are  two  values  in  type  bool  , 
an  infinite  number  of  values  in  type  int  ,  etc.)  Each  new 
type  in  a  hierarchical  data  abstraction  is  defined  by  the 
final  algebra  of  the  specification,  given  the  preceding 
definitions  for  all  of  the  old  types  in  the  specification. 

Figure  4-7  shows  the  relationship  between  the  initial 
and  final  algebra  interpretations,  using  the  lattice  of  all 
interpretations,  Lw  . 


5.  Implementations 


Just  as  the  collection  of  semantic  interpretations  of  a 
specification  can  be  described  by  quotient  algebras  of  a 
word  algebra,  the  collection  of  semantic  interpretations  of 
a  class  can  be  described  by  quotient  algebras  of  the  same 
word  algebra.  That  is,  every  class  has  an  associated 
signature,  which  yields  a  lattice  of  quotient  algebras.  All 
the  correct  semantic  interpretations  of  the  class  are 
contained  in  that  lattice. 
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5.1.  Classes 

DEFIN IT  ION  5.1  -  A  class  consists  of: 

(1)  A  signature  (S,F,V)  . 

(2)  Function  bodies  in  a  programming  language 
that  implement  each  function  in  the 
signature. 

(3)  Additional  functions  and  procedures  of  the 
programming  language  as  needed.  *** 

Figures  5-1  and  5-2  contain  classes  Natl8  and 
Stack  .  The  programming  language  used  is  SIMPL-D 
[Gannon  &  Rosenberg  79].  Objects  of  each  domain  are 
implemented  by  a  domain  record  of  previously-defined  types. 
Thus,  Natl8  is  implemented  by  a  record  with  one  field:  an 
int  variable.  The  type  1 n t  is  the  implementation-defined 
integer  type.  Values  of  type  Stack  are  implemented  by  an 
array  of  Nat  and  an  int  pointer.  Note  that  Stack  is 
bounded:  there  may  only  be  100  values  in  the  stack. 

The  functions  and  procedures  of  a  class  are  assumed  to 
terminate.  Also,  all  of  the  operations  in  the  signature  of 
the  class  must  be  functions.  Global  variables  and  side 


effects  are  disallowed. 


class  Nat  *  Zero,  Succ 

unique  lnt  Val 

Nat  f unc  Zero 
Nat  Result 
Result. Val  :■  0 
return(Resul t ) 

Nat  f unc  Succ(Nat  Arg) 

Nat  Result 
If  Arg. Val  *  17 

then  Result. Val  : *  0 

else  Result. Val  :*  Arg. Val  +  1 

end 

return ( Re sul t ) 


endclass 


Figure  5-1.  Implementation 
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class  Stack  -  Newstack,  Push,  Pop,  Tc 

unique  Nat  array  Vals(lOO) 

unique  Int  Tops 

Stack  f unc  Newstack 
Stack  Result 
Result. Tops  0 
return(Resul t ) 

Stack  f unc  Push(Nat  N,  Stack  S) 

Stack  Result 
i f  S.Tops  *  99 
then  return(S ) 

else  Resul t . Vais ( S .To p s )  :■  N 
Result. Tops  :*  S.Tops  +  1 
return(Result) 

end 

Stack  f unc  Pop(Stack  S) 

Stack  Result 
1 f  S.Tops  *  0 
then  return(S) 
else  Result  :■  S 

Result. Tops  Result. Tops  - 

end 

Nat  f unc  Top(Stack  S) 

Nat  Result 
1 f  S.Tops  *  0 

then  return(Zero) 

else  Result. Val  S  .  Va 1 s ( S . T o p s ) 
return(Resul t ) 

e  nd 

e  ndc las  s 


Figure  5-2.  Implementation  of  Stack 
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5.2.  Correctness 

The  lattice  of  semantic  interpretations,  Ly  ,  contains 
more  data  abstractions  than  are  correctly  implemented  by  a 
given  class.  In  particular,  the  data  abstraction  defined  by 
mod  1 3  (see  Section  3.3)  is  not  correctly  implemented  by 
the  class  in  Figure  5-1.  In  order  to  find  the  abstractions 
that  are  correctly  implemented,  we  must  formalize  what  it 
means  for  the  code  of  a  class  to  evaluate  a  constant  word. 

DEFINITION  5.2  -  The  exec  function  is  a  mapping 

from  W  into  the  semantic  domain  used  to  define 

c 

the  base  types  of  the  programming  language,  using 

the  meaning  of  the  functions  appearing  in  the 

constant : 

exec(f(w1 . w^))  *  (fJUwjJ . [wn])  * 

*  ** 

We  assume  that  the  given  programming  language  has  a 
semantics  that  defines  domains  of  values  for  all  Che  base 
types  of  the  language.  These  domains  may  be  sequences  of 
bits  or  lattices  in  a  denotational  semantics.  Any  given 
constant  expression  must  have  a  value  in  one  of  these 
domains.  The  bracket  notation,  due  to  (Kleene  52],  denotes 
the  function  computed  by  the  code  for  the  named  operation  on 
the  underlying  domain.  We  extend  the  notation  to  words  by: 

w  -  f(Wj  ,  ...  ,  wn)  implies 


lw]  -  [ f ] < [ w  x ]  ,  ...  ,  [wn]  )  . 

Because  we  have  assumed  totality  of  all  operations,  the 
function  denoted  always  exists. 

For  example,  the  operation  Zero  in  Natl8  (Figure 
5-1)  yields  a  certain  constant  bit  string  (the  constant  0 
in  the  base  type  int ) .  The  operation  Succ  in  Natl8  , 
when  applied  to  the  result  of  Zero  yields  another  bit 
string  (the  constant  1  in  the  base  type  int ) .  It  is 
possible  to  discover  the  functions  [Zero]  and  [Succ]  in 

Natl8  by  enumerating  all  their  possible  values  under  the 
exec  mapping  (one  value  for  [Zero]  ,  eighteen  for 
[Succ]  ).  In  general,  a  function  might  have  an  infinite 
number  of  values. 


DEF IN  IT  ION  5.3  -  Let  A  be  a  data  abstraction 

with  signature  (  £d  j  ,  ...  ,  ,  £f  . . ) 

and  C  a  class  with  the  same  signature,  but 
written  (^D^'  ,  ...  ,  Dr  1 J  ,  ^f  j  '  ,  ...  ,  f  m  '^  )  . 

We  say  that  A  is  correctly  implemented  by  C  if 
and  only  if  there  is  an  epimorphism 

R:  exec ( W ^ ) - >  A  .  That  is, 

R(exec(f1'(d1'  ,  ...  ,  d  ^  ’  ) ) ) 

f t (R( exec(d  1  '  ) ) . R ( exec ( d k '  )  )  ) 

for  all  dj'  ,  ...  ,  d^'  in  D  '  ,  ...  ,  Dk '  for 


all 


We  call  R  a  r epresentat ion  mapping. 


relationship  between  A  and  C 


Figure  5-3.  Correctness  of  implementations 
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Now  we  draw  a  parallel  between  specifications  and 
classes.  In  particular,  we  can  define  a  derivation*. 

DEFINITION  5.4  -  A  derivation 1  is  a  derivation 
(see  chapter  4)  with 

(4*)  If  exec(w^)  -  exec(w2>  then  w^  -  is  an 

equation 

substituted  for  rule  (4).  The  last  equation  in  a 
derivation'  is  the  equation  derived '  .  *** 

The  collection  of  words  derived 1  equal  defines  a 
relation  on  the  constant  word  algebra. 

DEFINITION  5.5  -  Two  elements,  w^  and  *2  ,  of 
the  constant  word  algebra  of  the  signature  of  a 
class  C  are  in  the  relation  conceq  if  and  only 
if  the  equation  w^  •  Wj  can  be  derived'  from 
C  .  We  say  that  w^  and  W2  are  equal  in 
conceq  .  *** 

Not  unexpectedly,  we  get  the  following  result. 

LEMMA  5.6  -  Conceq  is  a  congruence  on  Wc  . 

*  *  * 

PROP F  -  This  proof  is  identical  to  the  proof  that 
speceq  is  a  congruence  on  W£  (see  chapter  4), 
since  rule  (4)  for  derivations  is  not  used  in  that 
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proof .  *** 

DEFINITION  5.7  -  The  quotient  algebra  concalg 
of  a  class  C  is  defined  by  the  congruence 
conceq  of  C  : 

concalg  »  Wc  /  conceq  .  *** 

Because  concalg  contains  only  one  value  for  every 
collection  of  words  that  evaluate  to  the  same  value  in  the 
underlying  domain  of  the  programming  language,  concalg  is 
correctly  implemented. 

LEMMA  5.8  -  Given  a  class  C  ,  its  quotient 
algebra  concalg  is  correctly  implemented  by  C  . 

*  *  ★ 


PROP F  -  The  representation  mapping  from  C  to 
concalg  is  simply  the  identity  mapping,  which  is 
an  epimorphism.  *** 

The  algebra  concalg  is  the  algebra  of  the  underlying 
bit  strings  or  denotational  semantics  of  the  code  of  the 
class.  It  must  be  correctly  implemented  because  it  is 
exactly  Implemented.  However,  there  are  other  algebras  that 
are  correctly  implemented.  For  example,  concalg  of  the 
ciass  in  Figure  5-2  contains  different  values  for  the  words 
Po p ( Pus h(N ews tack , Ze r o ) )  and 

Pop(Push(Newstack,  Sue  c (Zero)))  ,  because  the  values  of  the 
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arrays  are  different  (at  location  Vals(O)).  The  normal 
algebra  of  a  stack  would  have  one  value  for  these  two  words. 
That  is,  the  representation  mapping  to  concalg  is  an 
isomorphism.  However,  any  epimorphic  image  is  correct. 

DEFINIT ION  5.9  -  A  quotient  algebra  is  said  to 
satisfy  a  class  if  and  only  if  it  is  an  epimorphic 
image  of  concalg  of  that  class.  *** 

THEOREM  5.10  -  A  data  abstraction  A  is 
correctly  implemented  by  a  class  C  if  and  only 
if  A  satisfies  C  .  *** 

PROOF  -  If  A  is  correctly  implemented  then  there 
exists  a  representation  mapping 
R:  exec(V?c)  -->  A  .  But,  exec(Wc)  ■  concalg  . 

So,  R  is  an  epimorphism:  R:  concalg  -->  A  . 

Thus,  A  satisfies  C  . 

If  A  satisfies  C  then  there  exists  an 
epimorphism  E:  concalg  -->  A  .  But,  E  is  then 
a  representation  mapping:  E:  exec(Wc)  -->  A  . 

So,  A  is  correctly  implemented.  *** 

For  example,  the  algebra  with  exactly  three  values  in 
domain  Nat  : 

Zero  -  Succ^(Zero)  -  Succ^(Zero)  ■  ... 

4 

Succ(Zero)  ■  Succ  (Zero)  -  ... 
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2  5 

Succ  (Zero)  -  Succ  (Zero)  «  ... 
is  correctly  implemented  by  Natl8  (see  Figure  5-1)  under 
the  representation  mapping: 


Val 

-  0,3,6,9,12 

or  15 

—  > 

Zero 

Val 

“  1,4,7,10,13 

or  16 

--> 

Succ( Ze  ro) 

Val 

-  2,5,8,11,14 

or  17 

—  > 

a. 

Succ  (Zero)  . 

Notice  that  it  is  up  to  the  user  of  the  class  to  define  and 
consistently  use  the  correct  representation  mapping. 

The  collection  of  correctly  implemented  data 
abstractions  is  closed. 

TH  EO  REM  5.11  -  The  collection  of  data 

abstractions  that  are  correctly  implemented  by  a 

class  form  a  complete  sublattice  of  L  .  We 

w 

denote  the  sublattice  L  .  *** 

c 

PROP  F  -  This  proof  is  identical  to  the  proof  for 
Lg  (see  chapter  4),  except  that  concalg  is 

used  instead  of  specalg  .  *** 

Figure  5-4  contains  the  lattice  of  all  correctly 
implemented  data  abstractions  for  the  class  in  Figure  5-1. 
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There  are  only  six  abstractions  in  the  lattice.  Comparing 
this  lattice  to  Figure  3-3,  we  see  that  it  is  a  sublattice 
of  the  appropriate  Lw  ,  but  a  different  sublattice  from 
Figure  4-4.  The  box  at  the  bottom  of  Figure  5-4  represents 
the  data  abstraction  with  18  different  values  in  Nat  .  The 
box  at  the  top  represents  the  trivial  algebra,  with  one 
value  in  Nat  . 
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6.  Specif ication/ Implementation  Intersection 

If  a  class  and  a  specification  share  the  same  signature 

they  can  be  compared.  In  particular,  if  the  same  collection 

of  data  abstractions  was  intended  to  be  described  by  both 

the  class  and  the  specification,  then  the  success  or  failure 

of  that  intention  can  be  described  in  terms  of  the  overlap 

of  the  two  lattices  L  and  L  .  When  the  overlap  is 

sc  v 

perfect,  i.e.  the  two  collections  are  identical,  then  total 
success  may  be  claimed.  To  measure  the  overlap,  we  use  the 
following  result: 

THEOREM  6.1  -  Given  a  specification  S  with 

signature  (D,F,V)  and  a  class  C  with  signature 

(D,F)  ,  the  collection  of  data  abstractions  that 

are  correctly  specified  by  S  and  correctly 

implemented  by  C  form  a  complete  sublattice  of 

L  and  L  .  We  denote  the  common  sublattice 
s  c 

SL  .  *** 

PROOF  -  Viewing  the  lattices  L  and  L  as 
-  s  c 

sets,  the  intersection  of  L  and  L  is  the  set 

s  c 

of  data  abstractions  that  satisfy  both  the 
specification  and  the  class.  Let  SL  be  that 
set.  SL  is  not  empty,  because  the  trivial 
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algebra  Is  In  both  L  and  L 

8  c 

The  lattice  operations,  meet  and  join  , 
are  the  same  for  Lg  and  Lc  .  So,  they  are 
defined  on  SL  .  We  need  to  show  that  SL  is 
closed  under  them.  Every  data  abstraction  in 

SL  is  defined  by  a  congruence  relation  . 

The  meet  of  any  two  algebras  is  defined  by  their 
congruence  intersection.  Join  is 
congruence-closure  union.  These  operations 
preserve  containment.  So,  the  meet  and  join 
of  two  congruences  containing  both  speceq  and 
conceq  is  a  congruence  containing  both  speceq 
and  conceq  .  *** 

The  sublattice  SL  contains  all  those  data 
abstractions  correctly  implemented  and  correctly  specified. 
There  are  four  possibilities:  (1)  SL  may  be  equal  to  Lg  , 
but  not  equal  to  Lp  ,  (2)  SL  may  be  equal  to  Lp  ,  but 
not  equal  to  Lg  ,  (3)  SL  may  be  equal  to  both  Lg  and 
L^  or  (4)  SL  may  not  be  equal  to  either  Lg  or  L^  . 

In  case  (1)  (  SL  ■  L  ,  SL  ^  L  )  the  collection  of 

s  c 

correctly  specified  data  abstractions  are  all  correctly 
implemented,  but  some  data  abstractions  that  are  correctly 
implemented  are  not  correctly  specified:  the  quotient 
algebra  concalg  contains  more  distinct  values  than  the 
quotient  algebra  specalg  .  If  agreement  was  intended  and 


the  specification  is  not  in  error,  two  remedies  are 
available:  (1)  the  collection  of  representation  mappings 
used  may  be  restricted  to  those  that  map  onto  specalg  or 
an  algebra  contained  in  Lg  ,  or  (2)  the  implementation  may 
be  changed  to  make  fewer  distinctions  between  values. 

If  the  implementation  is  correct,  but  the  specificatio 
is  wrong,  then  a  different  set  of  axioms  is  needed. 

Removing  axioms  will  (in  general)  increase  the  size  of  Lg 
but  may  not  produce  the  desired  9pecalg  .  Changing 
variables  to  constants  and  increasing  the  lengths  of  words 
have  a  similar  effect. 

In  case  (2)  (  SL  *  Lc  ,  SL  +  Lg  )  the  collection  of 
correctly  implemented  data  abstractions  are  all  correctly 
specified,  but  some  data  abstractions  that  are  correctly 
specified  are  not  correctly  implemented:  the  quotient 
algebra  specalg  contains  more  distinct  values  than  the 
quotient  algebra  concalg  .  If  agreement  was  intended,  and 
the  specification  is  in  error,  then  Lg  may  be  reduced  in 
size  by  adding  axioms.  Changing  constants  to  variables  and 
shortening  words  in  axioms  will  also  reduce  Lg  .  If  the 
implementation  is  wrong,  Lc  may  be  increased  by  various 
means.  Adding  new  fields  to  the  records  that  implement 
types,  increasing  the  number  of  control  paths  in  function 
bodies  and  lengthening  the  expressions  that  appear  in 
function  bodies  are  all  modifications  that  potentially 
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increase  L  . 

c 

In  case  (3)  (  SL  -  L  -  L  )  the  collections  of 

s  c 

correctly  specified  and  correctly  implemented  data 
abstractions  are  identical:  concalg  and  specalg  are 
isomorphic.  If  the  specification  is  wrong,  then  so  is  the 
implementation,  and  vice  versa.  If  either  one  is  known  to 
be  correct,  then  so  is  the  other. 

In  case  (4)  (  SL  +  Lg  ,  SL  j4  Lc  )  some  data 

abstractions  are  correctly  specified  but  not  correctly 
implemented,  and  some  data  abstractions  are  correctly 
implemented  but  not  correctly  specified:  neither  concalg 
nor  specalg  is  in  SL  .  If  the  desired  collection  of  data 
abstractions  is  contained  in  SL  ,  then  both  L  and  L 

SC 

may  be  reduced.  If  the  desired  collection  is  in  Lg  or 

L_  ,  but  not  the  other,  then  the  erroneous  lattice  must  be 
c 

expanded.  Otherwise,  both  lattices  must  be  expanded. 

Figure  6-i  shows  the  lattices  L  ,  L  and  SL  for 

s  ’  c 

the  specification  Natl2  (Figure  4-1)  and  the  class  NatlS 

(Figure  5-1).  It  is  an  example  of  case  (4)  (  SL  i1  L  , 

s 

SL  +  Lr  ). 
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If  Che  daCa  abstraction  with  six  values  in  Nat  was 
intended,  then  both  the  specification  and  the  class  may  be 
changed.  Adding  the  axiom: 

Succ^(Zero)  -  Zero 

shrinks  Lg  to  SL  .  Changing  the  test 
if  Arg . Val  *  17 

t  o 

i f  Arg . Val  »  5 

shrinks  L  to  SL  . 

c 

Although  the  techniques  for  changing  specifications  and 
classes  discussed  above  may  not  always  work  to  produce  the 
desired  lattice,  there  is  hope  that  some  sequence  of  changes 


will  work. 
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Table  Specifications 


Software  maintenance  is  facilitated  by  localization: 
the  confinement  of  required  changes  to  small  syntactic 
units.  Changes  to  axiomatic  specifications  do  not  seem  to 
have  this  property.  All  the  axioms  in  a  specification  need 
to  be  considered  together  in  making  any  change.  We  propose, 
therefore,  an  alternate  form  of  specification — table 
specifications. 

Table  specifications  are  weaker  than  axiomatic 
specifications  in  the  sense  that  the  set  of  all  data 
abstractions  specifiable  by  tables  is  a  subset  of  the  set  of 
all  data  abstractions  specifiable  by  axioms.  Table 
specifications  have  two  properties  that  axiomatic 
specifications  do  not  have,  however.  First,  changes  to 
table  specifications  are  more  clearly  localized  than  changes 
to  axiomatic  specifications.  Second,  there  is  a  natural 
correspondence  between  table  specifications  and 
Implementations  of  data  abstractions  that  preserves  the 
localization  property. 

Since  every  data  abstraction  is  uniquely  determined  by 
a  congruence  on  the  constant  word  algebra  of  its  signature, 
a  presentation  of  the  congruence  suffices  to  describe  the 
data  abstraction.  Furthermore,  the  division  of  types  into 


congruence  classes  is  often  mirrored  in  implementations  by 
division  of  functions  into  control  paths:  each  control  path 
of  a  function  handles  a  subset  of  congruence  classes. 

A  congruence  may  have  an  infinite  number  of  congruence 
classes.  (An  implementation  almost  always  defines  a  finite 
number  of  congruence  classes,  but  this  number  is  usually  too 
large  to  consider  explicit  enumeration  of  the  classes.)  On 
the  other  hand,  most  data  abstractions  decompose  into  a  very 
small  number  of  "patterns”  of  simple  structures.  That  is, 
each  value  of  the  data  abstraction  may  be  constructed  from  a 
subset  of  the  operations  in  the  signature,  and  the  other 
operations  may  be  defined  in  terms  of  this  subset  by  a  small 
set  of  simple  rules.  It  is  this  property  that  facilitates 
"data  type  induction"  [Guttag,  Horowitz  &  Musser  78]. 

The  rows  of  table  specifications  are  the  patterns  of 
congruence  classes  that  suffice  to  define  the  congruence. 

The  columns  are  operations.  The  entries  in  a  table  provide 
the  simple  rules  that  define  the  operations  in  terms  of  the 
rows.  When  a  congruence  has  a  finite  number  of  classes  of 
some  type  the  table  for  that  type  can  be  completely 
elaborated,  although  it  might  be  impractical  to  do  so.  In 
this  case  there  is  a  one-to-one  correspondence  between  rows 
and  distinct  values  of  the  type.  When  a  congruence  has  an 
infinite  number  of  classes  of  some  type,  a  small  number  of 
rows  (less  than  10)  is  usually  sufficient  to  describe  the 


patterns  of  congruence  classes.  However,  some  perverse 
types  do  not  have  any  finite  description  of  their  congruence 
classes. 
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7.1.  T-Gr  amma r  s 

It  will  be  convenient  (for  describing  congruence-class 

patterns)  to  use  a  new  notation  for  words  in  the  word 

algebra  of  a  signature.  We  will  drop  the  use  of  parentheses 

in  words  and  use  angle  brackets,  <  and  >,  to  delimit 

subwords.  This  does  not  introduce  any  ambiguity,  since  the 

leading  symbol  of  each  subword  has  a  constant  arity.  Thus, 

f(a,  g(b,  c))  becomes  < f > <a> <g> <b> <c>  .  Where  there  is 

no  ambiguity  we  will  drop  the  angle  brackets,  also.  So, 

<f><aXgXb><c>  becomes  fagbc  .  When  a  symbol  is 

repeated  an  exponent  will  sometimes  be  used.  For  example, 

3 

fa  is  an  abbreviation  for  fffa  .  This  new  notation 
suggests  two  kinds  of  patterns. 
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DEFIN IT  ION  7.1  -  Let  w  be  a  word  of  type  T  in 

the  word  algebra  W  (S,F,V)  containing  variables 

V.  ,  ...  ,  V„  of  types  T,  ,  ...  ,  T  in  S  . 

in  in 

The  set  of  all  words  o f  form  w  is  the  set  of  all 
words  in  W  (S,F,V)  obtained  by  substituting 
words  of  types  ,  ...  ,  Tr  for  variables 

Vj  ,  ...  ,  Vn  in  w  .  We  denote  this  set  by 

form(w).  The  set  formCR^.R^)  is  equal  to  the 
product  set  formCR^  x  form(R2>  .  Note  that 
w  4c  form(w)  .  The  set  o f  all  words  of 
r ightf ora  w  ,  denoted  by  r f orm(w)  ,  is  the  set 
of  all  words  In  W^(S ,F ,V)  of  the  form  Xw  , 
where  X  is  any  string,  including  the  null 
s  tr ing  .  *  ** 

Figure  7-1  contains  some  examples  of  form(w)  and 
rform(w)  ,  using  the  signature  of  Stack  in  Figure  4-2. 

A  useful  property  of  the  word  algebra  of  any  signature 
is  that  it  may  be  divided  into  a  collection  of  languages, 
generated  by  context-free  grammars. 


t o rm ( < S u c r > <N > )  ,  an  Infinite  set,  includes: 

<  S  u  c  c><Zero>  , 

2 

<Succ>  <Zero>  , 

<SuccXTopXS>  ,  etc. 

r f o rm ( <Suc c><N> )  ,  an  infinite  set,  includes: 

<SuccXN>  , 

<  S  uc  c>  2  <N  >  , 

<Succ>3<N>  ,  etc. 

f  o  rm  (  <Pu  shXZe  r  oXS  >  )  ,  an  infinite  set,  includes: 

<Push><Ze  roXNews  tack>  , 
<PushXZeroXPopXPushXNXS>  , 

<Push><Ze ro><S>  ,  etc. 

r  fo  rm(  <PushXZeroXS>  )  ,  an  infinite  set,  includes 

<PushXZeroXS>  , 

<Po  pXPu shXZe  roXS  >  , 

<T  o  pXPu  shXZe  roXS  >  ,  etc. 


Figure  7-1.  Examples  of  form(w)  and  rform(w) 
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DEFINITION  7.2  -  Let  T  be  a  type  in  the 
signature  (S,F,V)  of  a  data  abstraction.  The 
T-g  rammar  o  f  ( S , F  ,  V  )  is  the  4-tuple  (S,F,P,T)  , 
where 

(1)  The  set  of  nonterminals  is  S  ,  the  set  of 
type  names. 

(2)  The  set  of  terminals  is  F  ,  the  set  of 
operation  names. 

(3)  The  set  of  productions  P  is  defined  as 
f  o 1 lows : 

(a)  For  each  operation 

f:  Tx  x  ...  x  Tn  — >  T  ,  f  €  F  , 
there  is  a  production  T  fT^...Tn  . 

(b)  For  each  constant  operation  f:  -->  T  , 

f  €  F  ,  there  is  a  production 
T  : f  . 

(4)  The  start  symbol  is  T  ,  the  type  name.  The 

language  generated  by  (S,F,P,T)  is  called 
the  T-language  o  f  (  S  ,  F  ,  V  ) .  *** 

The  form  of  the  productions  guarantees  that  every  T-grammar 
is  context-free.  The  Nat-grammar  of  Stack  (Figure  4-2)  is 


shown  in  Figure  7-2. 


Nat-grammar  of  Stack  =  (S,F,P,Nat) 


S  =  Nat,  Stack 


F  =*  Zero,  Succ,  Newstack,  Push,  Pop,  Top 


P  »  <Nat>  : <Zero> 

<Nat>  <Succ><Nat> 

<N  a  t>  :  :»  <Top><Stack> 

<Stack>  ::=•  <Newstack> 

<  S  t  ack>  <Push> <N a t> <S t ack> 

<Stack>  <Pop><Stack> 


Figure  7-2.  The  Nat-grammar  of  Stack 


THEOREM  7.3 


Let  be  the  T^-language  for 

each  type  in  signature  (S,F,V)  .  The  union 

of  the  is  isomorphic  to  Wc(S,F,V)  .  *** 

PROOF  - 

(  W  (S,F,V)  S.  T-language  ) 

(Proof  by  induction  on  the  length  of  words) 

(Basis  step)  Let  f  be  a  word  of  type  T  in 

W  (S,F,V)  .  Because  f  is  a  constant,  there  is 
c 

a  production  T  : : *  f  in  the  T-grammar  of 
(S,F,V)  .  So,  f  is  an  element  of  the 
T-language. 

(Induction  step)  Now,  let  f(w^  ,  ...  ,  w^)  be  a 
word  of  type  T  of  length  k  and  w^  ,  ...  ,  w^ 
be  words  (of  length  less  than  k  )  of  types 
Tj  ,  ...  ,  Tn  in  W(,(S,F,V)  .  We  assume,  by 
induction,  that  the  words  w,  ,  ...  ,  w  are  in 
the  Tj-  ,  ...  ,  Tn~languages  .  There  is  a 

production  T  fTj...Tn  in  the  T-grammar.  So, 

there  is  a  word  fwj...w  in  the  T-language. 

(  T-language  C  W^(S,F,V)  ) 

(Proof  by  induction  on  the  length  of  words) 


(Basis  Step)  Let  f  be  a  word  in  the  T-language 
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of  (S,F,V)  .  Since  every  production  contains  a 
leading  terminal  symbol,  there  must  be  a 
production  T  f  in  the  T-grammar  of 


(S,F,V)  . 

But, 

that  means 

that  there  must 

be 

a  n 

ope  rat  ion 

f  :  -- 

->  T  in  (S 

, F , V )  .  So,  f 

i  s 

i  n 

Wc(S,F,V) 

• 

( Indue  tion 

Step) 

Now,  let 

fw. . . . w  be  a  word 

1  n 

i  n 

the  T-language 

of  length 

k  ,  s  o  w .  ,  .  . . 

> 

w 

n 

are  words  of  length  less  than  k  of  types 

T  i  »  •  •  •  » 

Tn  ‘ 

We  assume, 

for  induction. 

that 

w  i  »  •  •  •  i 

w 

n 

are  in  Wc(S 

, F ,V)  .  There  must 

b  e 

a  production  T 

: :»  fT , .  .  .T 
i  n 

in  the  T-grammar 

of 

(S.F.V)  , 

because  there  is 

a  production  for 

each 

function  in 

t  he 

s ignature . 

That  means  that 

t  he  re 

is  an  operation 

f  •  T  ^  x  •  •  • 

x  T  - >  T  in 

n 

(S.F.V)  . 

So  , 

fw^...wn  is  in  Wc(S,F,V) 

• 

*  *  * 

More  useful  for  our  purposes  than  context-free 
languages  are  regular  languages.  They  have  a  convenient 
notation,  regular  expressions,  that  may  be  exploited  in 
constructing  tables  and  in  generating  implementations. 
Unfortunately,  not  every  signature  guarantees  regularity  of 
T-languages.  Two  special  cases  guarantee  regularity. 

TH  EO  REM  7.4  -  All  T-languages  of  a  signature  with 
are  regular.  *** 


order  < 


1 
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PROP F  -  Each  operation  f  of  type  T  in  the 

signature  is  constant,  f:  - >  T  ,  or  has  one 

parameter  f:  T'  - >  T  .  The  productions  in  the 

T-grammar,  then,  are  of  the  form  T  f  or 

T  fT  '  .  So,  each  T-grammar  is  right-linear. 

*  *  * 

TH EO REM  7.5  -  If  a  hierarchical  specification  has 
TOI-order  < »  1  for  each  TOI  ,  and  each  TOI 

parameter  is  the  rightmost  parameter  in  its 
parameter  list,  then  the  TO I-languag e s  are 
regular.  *** 

PROP  F  -  Each  production  in  the  T^-grammar  is  of 

the  form  T,  : : »  f  or  T.  fT,...T  TOI  ,  where 

1  1  i  n 

Tj  ,  ...  ,  Tn  are  old  types.  This  grammar  is 

r ig h t- 1 i nea r.  *** 

The  Nat-grammar  of  Stack  (Figure  7-2)  is  regular.  The 
Nat-grammar  of  Natplus  (Figure  7-3)  is  not  regular,  because 
the  product! on 

<N'at>  <P1  u  s>  <N  a  t>  <N  a  t  > 


makes  the  Nat-order  two. 


Nat-grammar  of  Natplus  *  (S,F,P 


S  »  Nat 


F  -  Zero:  -->  Nat 

Succ:  Nat  -->  Nat 
Plus:  Nat  x  Nat  — >  Nat 


P  -  <N a t>  :  :«■  <Zero> 

<N  a  t>  :  :«  <SuccXNat> 

<N a  t>  :  <P1 us> <Na t> <Na t> 


Nat) 


Figure  7-3 


The  Nat-grammar  of  Natplus 
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7.2.  Constructors 

DEF IN  IT  ION  7.6-  A  set  o  f  constructors  o  f  type 
T  in  a  specification  (S,F,V)  is  a  subset 
R  «  ,  R2  ,  . . .  \  of  Wv(S,F,V)  ,  such  that 

every  constant  of  type  T  in  W  (S,F,V)  is  equal 
to  some  word  in:  form(R^)  U  formCR^)  U  ...  . 

When  formCR^)  A  form(R^)  is  empty  for  all 
i  +  j  the  set  of  constructors  is  called 
disjoint.  The  singleton  set  V  containing  only 
a  variable  with  domain  T  is  the  least  set  of 
constructors,  called  the  trivial  set  of 
construe  tors.  A  set  of  constructors  of  a  product 
of  types  T^  x  T2  is  the  product  R^  x  R2  of 
sets  of  constructors  for  the  individual  types  R^ 
for  T  ^  .  A  set  of  constructors  for  the  empty  set 
is  the  empty  set.  *** 

A  type  may  have  many  different  sets  of  constructors  in 
a  specification.  Figure  7-4  contains  a  specification  of  a 
type  with  three  different  nontrivial  sets  of  constructors. 
As  is  evident  from  the  example,  no  least  nontrivial  set  of 
constructors  need  exist.  The  greatest  set  of  constructors 
of  T  is  the  subset  of  all  elements  of  type  T  in 
Wv(S,F,/)  . 
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Although  some  specifications  are  not  regular,  an 
equivalent  regular  specification  of  the  constructors  can 
often  be  found  for  such  specifications.  It  is  an  open 
question  whether  a  regular  set  of  constructors  exists  for 
every  data  abstraction. 


7.3.  Tables 


A  disjoint  set  of  constructors  of  a  type  may  be  used  to 
describe  the  congruence  classes  of  that  type.  To  complete 
the  description  of  the  congruence  each  operation  must  be 
defined  in  terms  of  the  set  of  constructors.  When  the  set 
is  finite  a  table  may  be  constructed. 
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DEF IN  IT  ION  7.7-  A  table  specification  is  a 
regular  signature  (S,F,V)  and  a  finite  set  of 
triples,  called  tables ,  one  triple  for  each  domain 
arity  in  the  signature.  For  each  triple 
T  -  ( R  ,  C  ,  E )  : 

(1)  R  »  is  a  nontrivia^  >  finite  disjoint 

set  of  constructors  of  T  ,  called  rows. 

(2)  C  *  |f^  is  the  finite  set  of  functions 
of  domain  arity  T  ,  called  columns . 

(3)  E  is  a  function:  R  x  C  >  R'  ,  where  R' 

is  the  union  over  all  rows  in  all  tables  of 
the  specification.  E(r,c)  ,  where  r  £  R 
and  c  6  C  ,  is  called  the  (r.c)-entry  of 
the  table.  When  the  entry  is  the  word  or 
it  is  called  t  rivial . 

In  addition,  the  following  constraints  must  be 
met: 

(4)  For  each  nonconstant  row  R,  =  fw....w 

i  in’ 

where  f:  x  ...  x  Tn  - >  T  is  a  function 

in  F  ,  E( Wj . . . wQ , f )  -  Ra  . 

(5)  Each  variable  in  an  entry  appears  in  that 
entry's  row  name.  *** 

Figure  7-5  contains  a  table  specification  for  Sta<~ 
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Types:  Nat,  St  ack 

Functions:  Zero:  -->  Nat 

Succ:  Nat  -->  Nat 

Newstack:  — >  Stack 

Pop:  Stack  -->  Stack 

Top:  Stack  -->  Nat 

Push:  Nat  x  Stack  -->  Stack 


Variables:  N:  Nat,  S:  Stack 


Na  t 

Sue  c 

<Ze  ro> 

<Suc  c>  <Ze  r o> 

<Succ><N> 

<Suc  c>  2<N  > 

S  tack 

Pop 

Top 

<N  ews  tack> 

<Newstack> 

<Ze  ro> 

<PushXNXS> 

<S> 

<N> 

Nat  x  Stack  ] 

L 

Push 

(  <N  >  ,  <  S  >  ) 

M 

<PushXN  XS> 

Zero 


< Ze  r o> 


News  tack 


<N  ews  tack> 


Figure  7-5. 


A  table  specification  of 


Stack 
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There  are  four  tables:  Nat  ,  Stack  ,  Nat  x  Stack  and 
0  .  The  Nat  table  has  two  rows,  <Zero>  and 
<SuccXN>  ,  and  one  column,  Succ  .  The  rows  are  disjoint, 
because  form(<Zero>)  /\  f  o  rm  (  <Suc  c>  <N  >  )  »  0  .  Both  entries 
in  this  table  are  trivial.  The  Stack  table  has  two  rows, 
<Newstack>  and  <PushXNXS>  ,  and  two  columns,  Pop  and 
Top  .  None  of  the  entries  in  this  table  are  trivial.  Note 
that  the  variables  N  and  S  that  appear  in  entries  also 
appear  in  those  entries’  row  name,  <PushXNXS> 

(satisfying  condition  (5)).  The  Stack  x  Nat  table  has  one 
row,  the  trivial  set  of  constructors,  (<N>,<S>)  ,  and  one 

column,  Push  .  The  entry  in  this  table  is  trivial.  The 
last  table  contains  two  constant  functions,  Zero  and 
Newstack  .  Their  entries  are  trivial. 

A  table  specification  defines  a  unique  congruence  on 
the  constant  word  algebra  of  its  signature.  Thus,  it 
defines  a  unique  data  abstraction.  The  rows  of  the  tables 
define  the  congruence  classes.  The  columns  and  entries 
define  the  functions. 
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DEFINIT ION  7.8  -  Let  T  be  a  cable  specification 
with  signature  (S,F,V)  .  Let  w  be  a  word  in 
W  (S,F,V)  .  The  T-value  o f  w  ,  denoted  by 
eval (T ,  w)  ,  or  eval (w)  when  the  T  is  obvious 
from  context,  is  defined  recursively: 

(1)  If  w  is  a  variable,  then  eval(w)  =»  w  . 

(2)  If  w  is  a  0-ary  function  and  appears  as  a 

column  in  the  constant  table  of  T  ,  then 

eval(w)  is  the  entry  in  that  column.  If  it 
is  not  in  the  table,  then  eval(w)  is 
unde  fined. 

(3)  Otherwise,  w  »  f(x^  ,  ...  ,  x^)  .  Let 

yj^  »  evalCXj,)  ,  i  *  1  ,  ...  ,  n  .  If  any 

y^  is  undefined,  then  eval(w)  is 
undefined.  If  f  is  not  a  column  in  a  table 
in  T  ,  eval(w)  is  undefined.  Let 
R  »  (z,  ,  ...  ,  z  )  be  a  row  in  a  table  in 

T  such  that  y^  £  form(z  .  )  , 

i  ”  1,  ...  ,  n.  If  no  such  row  exists, 

eval(w)  is  undefined.  Otherwise, 
eval(w)  = 


E(R, f )  [ y 1  , . . .  ,  yn  /  z i  .... 

where  A[B1  ,...  ,  Bn  /  Cj  ,...  ,  C^j 
expression  formed  by  substituting 
every  occurrence  of 


is  the 
for 


in  A  , 


AD-A090  136  MARYLANO  UNIV  COLLEGE  PARK  COMPUTER  SCIENCE  CENTER  F/b  9 

DATA  ABSTRACTION  TRANSFORMATIONS. (U> 

AUG  60  M  A  ARDIS  F*»9620-80-C-0001 

nwrt  ASSlFTFn  rsc -TR-Q25 _ _ AFQSR"TR-B0~10fel  NL 


i  -  1 


•  •  • 


n 


*** 


For  example,  using  Che  cable  specification  of  SCack  in 
Figure  7-5, 

eval(Succ(Top(Pop(Push(Zero,Newstack) ) ) ))  ■  Succ(Zero)  . 
The  significance  of  Che  eval  funcCion  is  chac  ic  reduces 
words  co  forms  chac  appear  in  Che  cable  specif icacion 
enc  ries . 


DEFINITION  7.9  -  A  derivacion ' *  is  a  derivaclon 
(see  chapCer  4)  wich 

(4'')  If  evalCw^)  -  eval(w2)  Chen  -  w2 

is  an  equacion 

subsCiCuCed  for  rule  (4).  The  lasc  equacion  in  a 
derivacion' '  is  Che  equacion  derived  '  * .  *** 

DEFINIT ION  7.10  -  Two  elements,  Wj  and  w2  ,  of 
Che  consCanC  word  algebra  of  Che  signacure  of  a 
Cable  are  in  Che  relacion  tableq  if  and  only  if 
Che  equacion  w^  -  w2  can  be  derived''..  We  say 
Chac  Wj  and  w2  are  equal  in  tableq  and  write 

W .  tf.  _  It  &  it 

1  T  2  * 

LEMMA  7.11  -  Tableq  is  a  congruence  on 
Wc(S,F,V)  .  *** 


PROOF  -  This  proof  is  identical  to  Che  proof  that 
speceq  is  a  congruence  (see  chapter  4),  since 
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rule  (4)  for  derivations  is  not  used  In  Chat 
proof.  *** 

DEFINITION  7.12  -  The  quotient  algebra  tablalg 
of  a  table  specification  with  signature  (S,F,V) 
is  defined  by  the  congruence  tableq  : 

tablalg  »  Wc(S , F  ,V) /tableq  . 

We  say  that  the  table  specification  describes 
tablalg  .  *** 

A  table  specification  describes  a  data  abstraction.  We  need 
to  show  that  a  table  specification  exists  for  many  useful 
data  abstractions. 

THEOREM  7.13  -  There  exists  a  table  specification 
T  for  the  constant  word  algebra  of  any  regular 
signature  (S,F,V)  .  *** 

PROOF  -  Let  the  signature  of  T  be  (S,F,V)  . 

(1)  For  each  domain  arity  Ti  construct  a  table: 

(a)  Let  each  constant  function  f:  - >  T^ 

be  a  row. 

(b)  Let  each  function  f:  T^  — ~>  Tj  be  a 
column. 

(c)  For  each  function 

f:  T,  x  ...  x  T _ - >  T4  add  a  row 

1  tl  1 

fVr..V„  ,  where  each  Vj  is  a 


variable  with  domain  Tj  . 

(d)  Let  E ( R , f )  •  fR  ,  for  all  entries  in 

Ti  ‘ 

(2)  For  each  domain  arity  (T ^  ,  ...  ,  Tn> 
construct  a  table: 

(a)  Let  the  rows  be  the  set  R^  x  ...  x  Rr  , 
where  R^  is  the  set  of  rows  in  table 

Ti  * 

(b)  Let  each  function 

f:  T.  x  ...  x  T  - >  T.  be  a  column. 

1  n  l 

(c)  Let  E(R,f)  *  fR  .  for  all  entries  in 

(T^  i  ...  »  T  ^  )  * 

(3)  For  the  empty  domain  arity  (  )  construct  a 
table : 

(a)  Let  each  function  f: - >  T  ^  be  a 

c  o  1  urn  n . 

(b)  Let  0  be  the  only  row. 

(c)  Let  E(0,f)  «  f  ,  for  all  entries  in 

(  )  .  *** 


Figure  7-6  contains  a  table  specification  of  the  constant 
word  algebra  of  Stack  . 
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Types:  Nat,  Stack 

Functions:  Zero:  — >  Nat 

Succ:  Nat  — >  Nat 

Newstack:  — >  Stack 

Pop:  Stack  -->  Stack 

Top:  Stack  — >  Nat 

Push:  Nat  x  Stack  — >  Stack 

Variables:  N:  Nat,  S:  Stack 


Nat 

Succ 

<Ze  ro> 

<SuccXZero> 

<SuccXN> 

<Suc  c>  2<N  > 

<TopXS> 

<SuccXTopXS> 

Stack 

Pop 

Top 

<Newstack> 

<PopXNewstack> 

<TopXNewstack> 

<PopXS> 

<Pop>2<S> 

<TopXPopXS> 

<PushXNXS> 

<PopXPushXNXS> 

<T  opXPushXN  XS  > 

Nat  x  Stack 
(<N>,<S>) 


Push 


<PushXNXS> 


Zero 


<Ze  ro> 


Newstack 


<News  tack> 


Figure  7-6.  The  table  specification  of  of  Stack 


Comparing  the  table  specifications  of  Stack  in  Figures  7-5 
and  7-6,  we  see  that  there  are  no  rows  of  the  form 
<PopXS>  or  <TopXS>  in  Figure  7-5,  but  there  are  in 
Figure  7-6.  The  entries  in  Figure  7-6  are  all  trivial,  but 
the  entries  in  the  Pop  and  Top  columns  of  Figure  7-5  are 
not  trivial.  The  Stack  data  abstraction  described  in 
Figure  7-5  is  smaller  (it  has  fewer  values)  than  the  data 
abstraction  described  in  Figure  7-6. 

In  the  next  chapter  we  will  show  how  to  add  an  axiom  to 
a  table.  This  will  demonstrate  a  technique  for  changing 
specifications  in  addition  to  constructing  tables  for 
axiomatic  specifications. 
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8.  Transformations  of  Tables 


The  set  of  all  rows  in  a  table  specification 

with  signature  (S,F,V)  has  four  useful  properties: 

(Tl)  It  is  finite. 

(T2)  For  all  rows  Ri  ,  Rj 

formU^  ft  form(Rj)  -  0  .  (Disjoint) 

(T 3 )  For  every  word  w  (r  Wc(s,F,V)  there  exists 
a  row  R  and  a  word  w'  ,  such  that 
w  -T  w'  and  w'  6  form(R)  .  (Complete) 

(T 4 )  For  each  row  R  eval(R)  -  R  .  (Minimal) 

The  purpose  of  this  chapter  is  to  introduce  transformations 
on  table  specifications  that  preserve  these  four  properties. 

In  the  course  of  transforming  table  specifications  it 
will  frequently  be  convenient  to  change  the  domains  of 
variables  that  appear  in  tables.  For  example,  restricting 
the  domain  of  V  reduces  the  size  of  form(V)  ,  as  well  as 
reducing  the  size  of  form(fV)  ,  etc.  It  will  always  be 
possible  to  express  the  domain  of  a  variable  as  a  sum  of 
rows.  That  is,  for  each  variable  V  of  type  T  , 
dom(V)  -  form(R1)  u  ...  U  form(Rn)  ,  where 

,  ...  ,  Rnt  is  a  subset  of  the  set  of  rows  in  the 


table  T  . 
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Taking  advantage  of  this  fact,  we  will  explicitly 
denote  the  domains  of  variables  by  extra  columns  in  tables. 
Each  variable  will  have  a  column  in  its  type  table  with  an 
entry  of  its  name  in  every  row  of  its  domain.  These  extra 
columns  will  be  written  immediately  after  the  row-name 
column.  Figure  8-1  shows  the  Stack  table  specification  of 
Figure  7-5,  augmented  with  variable  columns  for  variables 
N  and  S  . 


Types:  Nat,  Stack 


Functions:  Zero:  — >  Nat 

Succ:  Nat  — >  Nat 

Newstack:  — >  Stack 

Pop:  Stack  — >  Stack 

Top:  Stack  — >  Nat 

Push:  Nat  x  Stack  — >  Stack 


Variables:  N:  Nat,  S:  Stack 


Nat 

N 

Succ 

<Ze  ro> 

N 

<SuccXZero> 

<Succ><N> 

N 

<Succ>2<N> 

Stack 

S 

Pop 

Top 

<Newstack> 

S 

<News  tack> 

<Ze  ro> 

<Push><NXS> 

S 

<S> 

<N> 

Nat  x  Stack 

Push 

(  <N  >  ,  <  S  >  ) 

<PushXNXS> 

0 

Zero 

News  tack 

<Zero> 

<N ews  tack> 

Figure  8-1.  Table  specification  of  Stack  with 
variable  columns 


Charts  «j»w 


d 


V"**- 
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We  will  observe  the  following  rules  for  variables: 

(VI)  Any  constant  word  f^...fng  may  be  written 

in  the  form  fj...fQV  »  where  dom(V)  •W- 
The  reverse  change  (writing  a  word  that 
contains  a  variable  as  a  constant)  may  also 
be  employed  where  appropriate. 

(V2)  If  two  variables  in  a  table  have  the  same 

domain  they  may  be  consolidated:  one  variable 
may  be  substituted  for  the  other,  leaving 
only  one  of  the  two  variables  in  the  table. 

( V 3 )  Variables  that  do  not  appear  in  any  row  names 
may  be  eliminated. 

(V4)  Whenever  a  row  is  removed  from  a  table,  that 
row  is  removed  from  all  variable  domains  that 
included  it.  If  a  variable  has  a  null  domain 
as  a  result  of  such  a  change,  all  rows  that 
include  that  variable  must  be  removed  from 
the  table. 

(V5)  When  a  row  is  added  to  a  table  no  variable 
domains  change,  unless  explicitly  noted. 

The  first  three  rules  are  for  convenience.  Rule  (VI)  makes 
it  possible  to  treat  all  row  names  as  if  they  contained  a 
variable.  Rules  (V2)  and  (V3)  cut  down  on  the  growth  of  new 
variables.  Rules  (V4)  and  (V5)  are  needed  to  explain  the 


•  ir  flint 


effects  of  transformations  on  the  domains  of  variables 
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8.1.  Benign  Transformations 

DEFINITION  8.1  -  A  change  to  a  table 
specification  that  preserves  properties  (Tl), 

(T2),  (T3)  and  (T4)  is  called  a  benign 
transformation.  *** 

All  of  the  transformations  defined  in  this  section  are 
benign. 

There  is  a  table  for  each  domain  arity  in  a 
specification,  not  each  type.  If  a  type  appears  in  a 
signature,  but  does  not  appear  in  the  domain  or  range  of  any 
function,  it  will  have  no  table  in  a  table  specification. 

We  call  these  types  null  types .  Addition  and  deletion  of 
null  types  are  benign  transformations. 

Addition  of  a  function  to  a  table  specification 

requires  defining  the  function  over  all  rows  in  its  domain 

arity  table.  This  may  be  done  by  defining  new  rows  in  the 

result  table:  the  result  of  applying  the  function  f  to 

( w,  ,  ...  ,  w  )  is  the  word  fw,...w  .  Since  all  the 
in  In 

added  entries  are  unique  and  distinct  from  all  other 
entries,  the  transformation  is  benign.  If  a  nontrivial 
function  is  desired  axioms  must  be  added  by  another 
transformation,  described  in  Section  8.3. 
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ALGORITHM  F  :  Add  a  Function 

Input:  T  :  a  table  specification  with  signature 

(  S  ,  F  ,  V ) 

f:  T ,  x  ...  x  T  >  T  :  a  function 

l  n  m 

distinct  from  all  those  in  F  , 
where  none  of  T  ^  ,  ...  ,  Tn_^  are 

the  TO  I 

Output:  T  :  a  new  table  specification 

Local  Variables:  R  :  a  row  name 

k  :  an  index  to  table  names,  as  in  T^ 

(FI)  Add  new  variables  ,  ...  ,  of  types 

Tj  ,  ...  ,  T  n  to  tables  T  ^  ,  ...  ,  Tn  in 

T  .  Let  domCV^  be  T.^  ,  i-1  ,  ...  ,n  . 

(F2)  Add  a  new  variable  to  each  table  T^  in 

T  .  Let  dom(W^)  be  empty. 

(F3)  Let  R  be  the  row  name  fV,...V  .  Let  k 

1  n 

be  m  . 

(F4)  Add  R  to  table  T^  with  trivial  entries. 
(F5)  Extend  dom(W^)  to  include  R  .  If  there  is 
a  V^  ,  extend  it  to  include  R  ,  if 
possible. 

(F6)  For  each  function 

f.:  T  x  ...  x  T ,  x  ...  T.  "  T  in  F  , 
i  a  k  be  ’ 

let  R  be  the  row  name  f.W  .  . .  W.  ...W,  .  If 

la  tc  b 

there  is  no  such  row  in  table  T  ,  let  k 

c  ’ 
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be  c  and  repeat  steps  (F4)  through  (F6). 

(F7)  Add  the  column  f  with  trivial  entries  to 

T  . 
m 

(F8)  Eliminate  any  variables  with  empty 

domains . 

( F 9)  Add  f  to  ( S , F  ,  V )  .  *** 

Adding  a  function  f:  T.  x  ...  x  T  -->  T  to  a  table 

i  urn 

specification  implies  adding  new  words  (some  of  which  are  of 

the  form  fV  ...V^  ^  Co  C^e  wor^  algebra  of  its  signature. 

Given  variables  V,  ,  ...  ,  V  with  domains 

1  n 

T.  ,  ...  ,  T  ,  the  row  fV,..,V  is  added  to  table  T 

i  n  In  m 

This  can  cause  a  "ripple"  effect  in  new  word  generation. 
Functions  that  include  in  their  domain  arity  produce 

new  words,  which  produce  new  words,  and  so  on.  To  close 
this  process  a  new  variable,  ,  is  introduced  for  each 

type  T^  .  Wi  "catches"  all  the  new  words  introduced  into 

type  T^  .  This  limits  the  ripple  effect  to  one  pass 

through  each  domain  in  each  domain  arity,  at  worst.  If  no 

new  words  are  added  to  a  type  Tj^  ,  the  variable  Wi  may  be 
eliminated.  An  example  of  adding  a  function  to  a  table 
specification  is  shown  in  Figure  8-2. 


101 


Original  table  specification: 
Types:  T  ^ 

Functions:  Z:  — >  T. 

S:  T.  — $  T. 

Variables:  N,  vj,  W][  :  Tj 


Z 

SN 


N 

N 


SZ 

s2n 


Function  to  be  added:  P:  T  ^  -->  T 


(FI): 


li-. 

N 

S 

z 

N 

vi 

SZ 

SN 

N 

vi  • 

s2n 

(  F2 ) : 


T1 

N 

V1 

s 

—  —  — 

■— — — 

— 

-■ 

z 

N 

V1 

SZ 

SN 

N 

V1 

2 

S  N 

( F 3 ) :  R  -  PV:  ,  k  -  1 


Figure  8-2  (Part  l  of  3).  Example  of  function  addition 


ft 


4 
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(F4.  1): 


( F  5  -  1 ) : 


( F6 .  1): 


Figure  8 


1 


Z 

SN 

PV, 


N 

N 


SZ 

s2n 


SPV, 


T1 

N 

V1 

W1 

S 

—  — 

z 

N 

V1 

SZ 

SN 

N 

V1 

S2N 

PVi 

V1 

W1 

SPV1 

R  *  SW  2  ,  k  -  1 


2  (Part  2  of  3).  Example  of  function  addition 
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Removal  of  a  function  is  not  a  problem  unless  the 
function  is  used  to  form  a  set  of  constructors.  If  it  Is, 
then  some  new  set  of  constructors  would  need  to  be  chosen, 
and  the  table  specification  changed  to  reflect  this,  before 
the  function  could  be  removed. 

ALGORITHM  D  :  Delete  a  Function 

Input:  T  :  a  table  specification  with  signature 

(  S , F , V) 

f:  T.  x  ...  x  T  -->  T  :  a  function  in 
i  n  m 

F  not  found  in  any  row  name  of 

T 

Output:  T  :  a  new  table  specification 

(Dl)  Remove  the  column  with  name  f  from  table 
(I  j  >  ...  ,  T  ^  )  in  T  . 

(D2)  Remove  the  function  f  from  (S,F,V)  .  *** 

Since  the  function  to  be  removed  does  not  appear  in  any  row 
name,  its  absence  will  not  affect  the  set  of  constructors  of 
any  type.  Also,  it  cannot  appear  in  any  entry  if  it  does 

not  appear  in  any  row  name.  Removal  is  as  simple  as 

deleting  one  column  from  one  table.  Figure  8-3  shows  the 
result  of  removing  the  function  Pop  from  the  table 
specification  of  Stack  in  Figure  8-1. 


Types:  Nat,  Stack 


Functions:  Zero:  — >  Nat 

Succ:  Nat  — >  Nat 
Newstack:  -->  Stack 
Top:  Stack  -->  Nat 
Push:  Nat  x  Stack  - 

Variables:  N:  Nat,  S:  Stack 


Nat 

N 

Succ 

<Ze  ro> 

N 

<Suc  c>  <Ze  ro> 

<SuccXN> 

N 

<Succ>2<N> 

Stack 

S 

Top 

(News tack> 

s 

<Ze  ro> 

<Push>  <N  ><S> 

s 

<N> 

Nat  x  Stack 


Push 


(  <N>,  <S>) 


<Push>  <N  >  <S  > 


0  1 

Zero 

Newstack 

<Ze  ro> 

<N  ews  tack> 

Star’ 


Figure  8-3.  The  result  of  deleting  Pop  froo  Figure  8-1 


106 


Two  more  benign  transformations  that  will  be  useful 
later  are  expansion  and  contraction  of  rows .  These 
transformations  have  no  semantic  effect:  the  output  table 
specification  describes  the  same  data  abstraction  as  the 
input  table  specification. 

ALGORITHM  X  :  Expand  a  Row 

Input:  T  :  a  table  in  a  table  specification 

R  ■  f,...f  V  :  a  row  in  T 
1  n 

Output:  T  :  a  new  table 

(XI)  For  each  row  R^  in  dom(V)  : 

(a)  Add  a  row  f....f  R.  to  T  . 

i  n  l 

(b)  Add  entries  to  fill  the  row: 

E(fl...fnR1  ,  f)  - 

E(fr..fnV  ,  f)  [Rt/V] 
for  each  column  f  in  T  . 

(c)  Extend  the  domains  of  all  variables 
defined  over  R  to  include  R^  . 

(X2)  Remove  the  row  R  from  T  .  *** 
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This  algorithm  takes  advantage  of  an  equation  that  holds  for 
all  tables: 

form(fVg)  -  form(fgj^)  CJ  ...  U  form(fgnVn) 

where 

d  om ( V  q  )  »  formCg^Vj)  U  ...  U  form(gnVn)  . 

Since  domains  of  variables  are  always  defined  in  terms  of 
rows,  such  an  equation  exists  for  every  row  .  The 

algorithm  substitutes  the  rows  on  the  right  side  of  the 
equation  for  the  row  on  the  left  side.  The  entries  are 
formed  by  substitution  of  the  appropriate  g^V^  for  vq  • 

An  example  of  expanding  a  row  is  shown  in  Figure  8-4. 


Expanding  a  row  Is  useful  when  one  of  Che  new  rows  can 
be  eliminated  by  another  transformation.  Such 
transformations  will  be  described  in  Section  8.3. 

The  opposite  of  expansion  of  a  row  is  contraction  of 
rows.  Contraction  is  possible  whenever  two  rows  have 
similar  entries  due  to  a  common  prefix.  That  is,  a  more 
"general"  row  could  be  defined,  such  that  each  of  the  two 
original  rows  is  an  "instance"  of  the  general  row.  For 
example,  rows  that  arise  from  expansion  of  a  row  R  may  be 
contracted  into  the  row  R  ,  since  the  expanded  rows  are  all 
instances  of  R  . 

Let  Rx  -  f1...fng1...gmV1  and  R2  -  f i . . . f ^ . . .h^ 

be  two  rows  to  be  contracted  into  R  *  f,...f  V  .  Then 

i  n 

three  properties  must  hold: 

(PI)  form(R)  -  form(Rj)  U  form(R2) 

(P2)  For  all  columns  f  in  T  there  exist  words 
e(R,f)  in  Wv(S,F,V)  ,  such  that: 

(a)  E (R x  ,  f )  « 

e(R,f)  [gr  ..gmV1/V] 

(b)  E ( R  2  ,  f  )  - 

e( R , f ) [hj . ..hkV2/V] 

(P3)  There  is  no  variable  whose  domain  includes 
Rj  but  not  R 2  ,  or  vice  versa. 

Property  (PI)  guarantees  chat  R  may  be  substituted  for  the 


pair  of  rows  R^  and  R2  without  changing  the  constructor 
set  of  the  table.  Property  (P2)  guarantees  that  the 
evaluation  of  any  word  will  be  the  same  before  and  after  the 
contraction.  Property  (P3)  prevents  the  side  effect  of 
increasing  the  size  of  the  constructor  set  by  increasing  the 
domains  of  variables. 

ALGORITHM  C  :  Contract  Rows 

Input:  T  :  a  table  in  a  table  specification 

with  signature  (S,F,V) 

R1  *  f 1* *  ,fngl*  * ,gmVl  » 

R2  *  f  ^  .  .  .  f  nhj  .  .  .hjtV2  :  rows  in  T  , 

n  >-  0 

R  *  f j. . .fnV  :  a  new  row  to  replace  R ^ 
and  R2  ,  such  that  properties 
(PI),  ( P2 )  and  (P3)  hold. 

Output:  T  :  a  new  table 

(Cl)  Add  the  row  R  to  T  ,  with  entries 

E(R,f)  -  e(R,f)  for  each  column  f  in  T  . 

(C2)  Extend  the  domains  of  variables  defined  over 
Rj  and  R2  to  include  R  . 

( C 3 )  Remove  rows  R^  and  Rj  from  T  .  *** 

An  example  of  contraction  of  rows  is  shown  in  Figure  8-5. 
Note  that  the  resulting  table  is  the  same  as  the  input  table 
of  Figure  8-4. 
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Input 

T  - 


R 


1 


R 


2 


R  - 


Note : 


T1 

N 

1  vi 

s 

p 

..... 

- 

z 

N 

V1 

sz 

PZ 

SN 

N 

V1 

s2n 

PSN 

PV1 

V1 

W1 

SPV1 

P2Vi 

SPVX 

V1 

w 

1 

S2PV1 

PSPV1 

s2w 
b  1 

V1 

w 

W1 

S3W1 

PS2W 

-  SPVj  (fj  -  S  ,  gj  -  P  ,  Vj  -  Vj) 

-  S2W1  (fj  -  S  ,  hj  •  S  ,  V2  -  Wj) 


swx  (fx  -  S  ,  V  -  wA) 

(1)  f  o  rm  ( SW  x )  -  form(SPV1)  U 
(2a)  E(SPV1,S)-S2W1[PV1/W1]  , 
(2b)  E(S2W1,S)-S2W1[SW1/W1)  , 


form(S2Wj) 

E(SPVX ,P)*PSW1 [PVj 

e(s2w1 ,p)-psw1 [SW  x 


/Wj] 

/wx] 


(Cl): 


T1 

N 

V1 

w 

-• 

s 

p 

- - — -  — 

z 

N 

V1 

sz 

PZ 

SN 

N 

V1 

s2n 

PSN 

PV1 

V1 

W1 

SPV1 

P2Vi 

SPV1 

V1 

W1 

S2PV1 

PSPV1 

S2Wl 

V1 

W1 

S3Wl 

PS2W: 

SW  { 

:* 

CN| 

c n 

PSW1 

r 


i 


\ 

i 


Figure  8-5  (Part  1  of  2).  Example  of  row  contraction 


1  14 


8.2.  Rewrite  Sets 

By  Lemma  7.11  a  table  specification  defines  a 
congruence  on  the  constant  word  algebra  of  its  signature. 
More  than  that,  it  defines  a  set  of  rewrite  rules.  Given 
two  different  words  w^  and  »  such  that 

eval(Wj)  -  eval(w2)  and  w^  *  eval(' , )  ,  the  rewrite  rule 
w 2  — >  Wj  may  be  derived.  By  changing  table 
specifications  we  change  the  derived  rewrite  rules.  Looking 
at  it  from  the  other  direction,  we  need  to  know  which 
rewrite  rules  we  want  before  we  can  change  the  table 
specification.  To  do  this,  a  total  order  on  each  type  is 
def ined . 


DEFINITION 

8. 

2  - 

Let 

( S , F , V )  be  a  regular 

signature. 

Let  F 

be  partitioned  into  the 

set 

constant  functions 

i 

k^  and  nonconstant 

f  unct Ions 

h 

a- 

We 

define  a  total  order 

£ 

each 

type 

in 

Vs 

,F, 

V)  by  first  defining 

<* 

(1) 

i  < 

j 

--> 

k 

i  <*  kj 

(2) 

i  < 

j 

--> 

f 

i  <*  fJ 

(3) 

i  < 

j 

--> 

V 

i  <*  VJ 

(4) 

ki 

<* 

vj 

for 

all  ^  ,  Vj 

(5) 

Vi 

<* 

fj 

for 

all  Vt  ,  fj 

Le  t 

£  be 

lexicographic  ordering  of  strings 

» 

using 

<* 

t  0 

com  pare 

individual  symbols.  *** 
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Note  that  it  will  never  be  necessary  to  compare  function 
symbols  of  different  types.  Figure  8-6  shows  the  standard 
order  on  Stack  (Figure  8-1),  given  the  naming  convention 
shown.  Our  algorithms  will  be  defined  so  that  all  tables 
will  follow  the  standard  order  in  all  implied  rewrite  rules. 

DEFINITION  8.3  -  Let  T  be  a  table 
specification.  The  rewrite  set  of  T  is  the  set 
of  all  pairs  (fw.....w  ,  R)  ,  usually  written  in 
the  form  fw^...wn  -->  R  ,  one  pair  for  each 
nontrivial  entry  R  »  E(w^...w  ,  f)  .  *** 

For  example,  the  rewrite  set  of  Stack  (Figure  8-1)  is 
£  <PopXNewstack>  — >  <Newstack>  , 

<PopXPush><NXS>  — >  <S>  ,  <TopXNewstack>  — >  <Zero>  , 
<TopXPushXNXS>  -->  <N>  ^  .  The  function  eval  uses  the 
entries  in  a  table  specification  to  rewrite  any  word  to  a 
canonical  term.  By  virtue  of  the  table  properties  (Tl) 
through  (T4)  the  rewriting  is  always  convergent 
[Musser  79b].  That  is,  a  unique  term  is  always  produced 
after  a  finite  number  of  rewriting  steps. 


Naming  Convention: 


Nat:  -  <Zero> 

■  <Succ> 
f2  -  <Top> 

V  -  <N> 

Stack:  k^  »  <Newstack> 

-  <Push> 
f2  *  <Pop> 
vx  -  <S> 

Standard  Order: 

Nat:  <Ze  ro>  £  <N>  £  <Succ>  £  <Top> 

Stack:  <Newstack>  £  <S>  £  <Push>  £  <Pop> 

Examples  : 

<Succ>^<N>  £  <Top> <N ews tack> 
<PushXZero><Pop><Push><NXS>  £ 

<PopXNewstack> 


Figure  8-6.  The  standard  order  on  Stack 
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Some  changes  Co  a  cable  s pecif icacion  cause  Che  rewrlce 
sec  of  some  Cable(s)  Co  become  IncompleCe:  chey  are  no 
longer  convergenC.  An  algorlchm  for  compleCing  an 
IncompleCe  sec  of  rewrlce  rules  is  described  in 
[KnuCh  &  Bendix  70].  Unf o rtunaCely  ,  Chis  algorlchm  does  not 
always  CerminaCe.  We  give  here  a  modified  version  of  pare 
of  Che  Knuch-Bendix  algorcihm.  Our  algorlchm  always 
cerminaCes,  buc  ic  may  have  co  be  used  an  infinice  number  of 
times  Co  compleCe  a  rewriCe  sec.  A  useful  sub— algori thm  is 
defined  firsC. 


jl 
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ALGORITHM  G  :  Generate  Rewrite  Rules 

Input:  T  :  a  table  specification  with  signature 

(  S  ,  F  ,  V ) 

x2)  :  a  pair  of  words  in  Wv(S,F,V) 
Output:  P  -  C(Li »  :  a  set  of  pairs  of  words 

in  wv(S,F,V)  to  be  used  in 
rewriting: 

Local  Variables:  0  -  f(w  ,w.  )\  :  a  set  of  pairs 

1  2 

of  words  in  Wv(s,F,V)  defined  in 
T 

(Gl)  Let  0  and  P  be  empty  sets. 

(G2)  If  both  x^  and  x2  are  defined  in  T  let 
0  be  the  set  £(x^,  x2^  •  Otherwise, 
substitute  all  rows  in  the  domains  of 
variables  in  x^  and  x2  for  those 
variables,  generating  a  set 

0  "  £(wi  .*!>?• 

1  2 


For 

each 

pair  (wL, 

w2) 

in  0  : 

(a) 

Compute  w^ '  ■ 

eval(Wj)  , 

w  * 
2 

■  eval(w2 

)  . 

(b) 

If 

V  <  w2  ' 

add 

w2  '  — >  W  j  '  to  P  . 

If 

w2 '  <  V 

add 

w^  '  — >  w2 '  to  P  . 

(Otherwise,  w^ '  ■  w2 '  ,  a  trivial 
rewrite  rule.)  *** 
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This  algorithm  consists  of  two  major  steps:  (G2)  and  (G3). 
The  first  step  generates  a  set  of  pairs  of  words.  Each 
member  of  each  pair  is  a  word  defined  in  the  table 
specification.  The  second  step  orders  the  pairs  by  the 
standard  order. 

The  first  step  is  needed  whenever  a  word  in  the  input 
pair  is  in  "too  general"  form  for  the  table.  That  is,  the 
input  word  is  of  the  form  f^...f  ,  but  there  are  rows  in 

the  table  specification  of  the  form  f,...f  g,...g  V_  .  In 
this  case  the  variable  must  be  expanded  in  exactly  the 

same  way  that  a  row  is  expanded.  Each  row  in  the  domain  of 
V j  is  substituted  for  ,  generating  a  set  0  of  pairs. 
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ALGORITHM  K  :  Complete  a  Rewrite  Set 

Input:  T  :  a  table  specification  with  signature 

(S  ,F,V) 

0  -  {(Llf  R1)J  :  a  set  of  pairs  of 


words  in  W  (s,F,V)  ,  the  original 


Output : 


Local  Variables: 


rewrite  set 

^L^  — >  :  a  new  rewrite  set 

disjoint  from  0 

P  ■  C Li  — >  Ri^  :  a  set 
rewrite  rules  generated  from 

Algorithm  G 


-  \ 
H 


!  ; 


f  i 


B 

m 

’  Li  ' 
x2 

->  %  >5  !  * 

1 

set  of 

pairs 

of  rewrite  rules 

C 

t 

b±l  : 

a  set  of  words  in  Wv(S,F,V) 

representing 

overlapping  of  rewrite 

rules 

(Kl) 

Let  N 

be  an  empty  set 

• 

(K2) 

Using 

all 

pai  r  s 

(L,  R) 

in  0 

generate  a 

set  of 

rewrite  rules  P 

,  using 

Algorithm  G. 

(K3) 

Add  to 

N 

each 

rewrite 

rule  in 

P  that  is 

not  in 

0 

• 

(K4) 

Form  the 

set  B 

">  Rt 

1  1 

» 

Lt  “ 

-> 

A 

of  all 

pairs  of 

r ewr i te 

*2 

12 

rules 

in 

0  U  N 

e 

(K5) 

If  B 

i  s 

empty 

quit. 

i 


(K6)  Select  an  element  (  , 

Lj  — >  R 2  )  of  B  ,  and  remove  it  from  B  . 
(K7)  Form  the  set  C  -  £  f  ^  .  . .  f  ng  1 .  .  .gmh  ^ 

(where  m  >-  1 ,  n  >■  0,  k  >-  0)  of  all 
"overlaps"  of  and  >  where 


L1  "  f  1*  *  *  f n8 1  *  8m^ 1  * 


L2  "  gl*  **8mhl*  “hkV2  *  and 

domCVj)  2  form(h^ . . .h^V2 )  .  C  may  be 

empty. 

(K8)  For  each  element  of  C  generate  a  rewrite 


set  P  ,  using  Algorithm  G  with  w^  -  R  and 


w «  *  f,...f  R-  .  Add  to  N  each  rule  in 
l  l  n  L 


P  that  is  not  in  0  . 

(K9)  Repeat  steps  (K5)  through  (K9).  *** 


This  algorithm  finds  Implied  rewrite  rules,  given  a  rewrite 
set  and  a  table.  Several  invocations  of  the  algorithm  may 
be  needed  to  complete  a  rewrite  set.  Algorithm  G  is  used  to 
generate  a  set  of  rewrite  rules  from  input  pairs  of  words. 
This  is  necessary  for  those  cases  where  the  table 
specification  has  a  rewrite  set  that  is  different  from  the 
one  input  to  the  algorithm.  Such  cases  arise  in  Algorithm 
A,  defined  in  the  next  section. 


To  find  implied  rewrite  rules,  each  pair  of  rewrite 
rules  is  checked  for  "overlap."  If  a  word  can  be  rewritten 
in  two  different  ways  (an  overlap),  a  new  rewrite  rule  is 


r 

A 


<  ' 


'  . . ******* 


i 


generated.  Overlapping  in  regular  signatures  can  only  occur 
in  one  form:  fghV  — >  ahV  and  fghV  — >  fbV  ,  where 
fgV  — >  aV  and  ghV  — >  bV  are  rewrite  rules,  and  f  , 
g  and  h  are  subwords  of  any  finite  length. 

An  example  of  completing  a  rewrite  set  is  shown  in 
Figure  8-7.  In  the  example  Algorithm  K  is  invoked  twice. 

An  example  that  does  not  converge  is  shown  in  Figure  8-8. 

In  this  example  each  invocation  of  Algorithm  K  generates  a 
new  rewrite  rule  that  requires  another  invocation  of 
Algorithm  K. 


123 


Types: 

Functions:  Z:  — >  T 


0  -  {<S2Z,  Z>,  <S5Z,  Z>\ 


First  invocation  of  Algorithm  K: 

(Kl)  N  -  0 

(K2.1)  Invoke  Algorithm  G  with  x^  -  S2Z  ,  -  Z 

(Gl)  0-0 
(G2 )  0  -  <S2Z,  Z> 

( G3 )  (a)  wx  *  -  S2Z  ,  w 2  *  —  Z 

(b)  p  -  £s2z  — >  z  1 
P  -  ?s2z  — >  z\ 

(K2.2)  Invoke  Algorithm  G  with  x^  -  S^Z  ,  X2  -  Z 
P  -  |s2z  —  >  Z  ,  S5Z  ~ >  Z 1 


Figure  8-7  (Part  1  of  3).  Example  of  rewrite  set  completion 
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(K3)  N  -  0 


(K4)  B 


t 


2 

<  S*Z 

2 

<  S*Z 

<  S5Z 

<  s5z 


— >  z  ,  s‘z 

— >  z  ,  S5Z 

— >  z  ,  s2z  - 

— >  z  ,  s5z 


>  z  >  , 

>  z  >  , 

->  Z  >  , 

>  z  >  ^ 


(K6.1)  Select  <  S2Z  -->  Z  ,  S2Z  — >  Z  > 


(K7.1)  C  ■  £s2Z^  (  S2Z  overlaps  with  itself  trivially.) 


(K8.1)  P  «  f 


S^Z  — >  Z 


\  ,  H  -  * 


(K6.2)  Select  <  S2Z  — >  Z  ,  S5Z  — >  Z  > 


(K7.2)  C  ■  0  (No  overlaps) 

(K8.2)  P  -  0  ,  N  -  0 


Figure  8-7  (Part  2  of  3).  Example  of  rewrite  set  completion 


(K6.3)  Select  <  S  Z  — >  Z 


S  Z  — >  Z  > 


(K7.3)  C  -  £s5z"$  ( f !  f  2  f  3  -  S3  ,  g^  -  S2  ,  Vj  -  V2  -  Z) 

(K8.3)  P  -  £s3Z  — >  zl,  ,  N  «  S3Z  — >  Z 

(K6.4)  Select  <  S5Z  — >  Z  ,  S5Z  -->  Z  > 

B  -  0 

(K7.4)  C  -  fsh\  (Trivial  overlap) 

(K8.4)  P  -  £s5Z  -->  ,  N  -  £s3Z  —  >  zl 

(K5.5)  B-0  ■■>  quit 

Second  invocation  of  Algorithm  K: 

0  -  £s2z  — >  Z  ,  S5Z  —  >  Z  ,  S3Z  —  >  z| 

Result:  N  -  SZ  — >  Z 

0  U  N  is  a  complete  rewrite  set 

Figure  8-7  (Part  3  of  3).  Example  of  rewrite  set  completion 


126 


Types:  D 

Functions : 

Variables : 


h:  —  >  D 
f:  D  — >  D 
g:  D  — >  D 
V:  D 


D 

V 

f 

g 

h 

V 

fh 

gh 

fV 

V 

f  2V 

gfV 

gv 

V 

fgv 

g2v 

MK 

O  -  {<fgfV,  gfv>1 

Note:  Standard  order  must  be:  h  f 

Otherwise,  gfV  — >  fgfV  — >  f 


First  invocation  of  Algorithm  K: 

fgfgfV  — >  gfgfV  — >  g2fV  and 

fgfgfV  — >  fg2fV 

So,  N  -  £<fg2fV,  g2fV>1 

Second  invocation: 

f  g  2  f  g  f  V  — >  g  2  f  g  f V  — >  g3fV  and 

fg2fgfV  — >  fg3f V 

So,  N  *  £<fg3fV,  g3fV>3 


£  8 

gfV  — > 


Figure  8-8.  Example  of  non-convergent  rewrite  set 
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8.3.  Adding  Axioms 

Adding  an  axiom  to  an  axiomatic  specification  usually 
changes  the  lattice  of  specified  data  abstractions.  When  it 
does,  it  shrinks  the  lattice  by  eliminating  some  data 
abstractions.  The  corresponding  change  to  a  table 
specification  is  a  change  in  the  rows,  the  constructors  of  a 
type.  Given  an  axiom,  the  appropriate  row  changes  can 
sometimes  be  made  so  that  tablalg  ■  specalg  .  This 
cannot  be  done  when  the  use  of  Algorithm  K  fails  to 
converge. 

Two  algorithms  are  defined  for  adding  axioms  to  table 
specifications.  The  first  algorithm  changes  the  constructor 
set  of  a  type  by  removing  a  row  and  all  words  that  contain 
that  row  as  a  rightmost  subword.  It  is  invoked  by  the 
second  algorithm,  the  algorithm  to  add  an  axiom. 
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ALGO R ITH M  R  :  Remove  a  Row 

Input:  T  :  a  table  in  a  table  specification 

T  ' 

R  ■  f , . . . f  V  :  a  row  in  T 
i  n 

Output:  T  :  a  new  table 

Local  Variables:  k  :  an  integer 

W  :  a  variable  in  the  signature  of  T' 
of  type  T 

R'  -  g,...g  f .  .  .  .f,  X  :  a  row  in  T 
1  m  1  k 

(Rl)Let  k  be  n. 

( R  2 )  If  k  «  0  quit. 

( R 3 )  Let  W  be  a  new  variable  with 
dom(W)  -  f o rm ( f .  . . f nV  )  . 

(R4)  For  each  row  R'  -  g ^ .  . . g^ f  .  . . f ^X  in  T  , 
m  >»  0  ,  where  dom(X)  2  dom(W)  : 

(a)  Replace  X  with  a  new  variable  X'  : 

dom(X')  *  dom(X)  -  dom(W)  . 

(b)  If  dom(X')  is  empty  remove  R'  from 

T  . 

(R5)  Subtract  l  from  k  ,  and  repeat  steps  (R2) 
through  ( R5  ) .  **  * 

Given  a  word  V  ,  Algorithm  R  eliminates  words  in 

l  n  n 

r  f  o  rm  (  f  ,  .  .  .  f  V  )  ,  rform(f  ...f  V  ,)  ,  ...  ,  and 

Inn’  1  n- 1  n-1  ’ 

rforra(f^Vj)  ,  in  that  order  (where 
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dom(V^)  H  f o rm ( f . . . f nVn )  ).  It  does  this  by  changing 
the  domains  of  variables  in  row  names.  Each  word  to  be 
eliminated  is  removed  from  the  domains  of  variables.  For 
example,  if  fV^  is  to  be  eliminated,  and  there  is  a  row 
gfVj  ,  where  domCVj)  »  form(gfV^)  U  form(hV2)  ,  then  a 
variable  change  is  made: 

gfV^  -->  gf/^  ,  dom( )  »  form(hV2)  . 

If  a  variable's  domain  becomes  empty  as  the  result  of  such  a 
change  the  row  containing  that  variable  is  removed  from  the 


table. 
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ALGORITHM  A  :  Add  an  Axiom 

Input:  T  :  a  table  specification  with  signature 

(  S  ,  F  ,  V ) 

^”1*  “2^  :  a  Pair  words  in 

W  (S,F,V)  ,  the  axiom  to  be  added 
Output:  T  :  a  new  table  specification 

Local  Variables:  P  »  |  Li  — >  :  a  set  of 

rewrite  rules  generated  from  the 
axiom 

0  ■  ^Li  — >  :  the  original  rewrite 

set  generated  from  T  extended  by 
calls  to  Algorithm  K 
L  — >  R  :  a  particular  pair  from  P 
T'  :  a  table  in  T 

(Al)  Let  0  be  the  rewrite  set  of  T  . 

(A2)  Using  Algorithm  G,  generate  a  set  P  of 
rewrite  rules  from  the  axiom  <w^,  W2>  • 

(A3)  If  P  is  empty  quit. 

(A4)  Remove  a  rule  L  — >  R  from  P  .  Add  the 
selected  rule  to  0  . 

( A5 )  Expand  rows  (Algorithm  X)  until  L  is  a  row 
in  some  table  T '  . 

(A6)  Remove  L  from  T'  (Algorithm  R). 

(A7)  Substitute  R  for  L  in  all  entries  of  T  . 
(A8)  Using  Algorithm  K,  complete  the  rewrite  set 
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0  with  the  table  specification  T  .  Add 
the  new  set,  N  ,  of  rewrite  rules  to  P  and 
to  0  . 

(A9)  Repeat  steps  (A3)  through  (A9).  *** 

Each  axiom  to  be  added  to  a  table  is  transformed  into  a  set 

of  rewrite  rules,  using  Algorithm  G.  Each  rewrite  rule  is 

processed,  yielding  a  new  rewrite  set.  Algorithm  K  is  then 
used  to  complete  the  rewrite  set.  Because  new  rewrite  rules 
may  need  to  be  added,  an  iterative  process  is  necessary.  In 
those  cases  where  no  convergent  rewrite  rule  set  can  be 
formed,  the  algorithm  does  not  terminate. 

For  each  rewrite  rule  to  be  processed  the  table 
specification  is  changed  by  eliminating  all  occurrences  of 
the  left  side  of  the  rewrite  rule.  Algorithm  R  is  used  to 
eliminate  occurrences  in  row  names.  Substitution  of  the 
right  side  of  the  rewrite  rule  is  used  for  entries.  An 

example  of  axiom  addition  is  shown  in  Figure  8-9. 
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Types:  T1 

Functions:  Z: 


I 


Va  riables 
T  -  T 
Z 

PV 


1 


sv, 


•>  T 


P:  Tx  —  >  Tj 
S:  T  L  — >  T  j 

Vi:  Tj  ,  i-1,2,... 


P 

PZ 

PSV, 


s 

sz 

SPV 

s2v 


1 


z 

+■ — 
z 


Note:  This  table  will  not  change. 


<  w^  ,  v*2  >  *  <  S4Z  ,  Z  > 

(Al)  0-0  (Every  rewrite  rule  in  T  is  trivial.) 


(A2)  Use  Algorithm  G  to  generate  rewrite  rules: 
P  -  l  S4Z  — >  zl 

( A4 )  Select  S4Z  — >  Z  from  P 


Figure  8-9  (Part  1  of  9).  Example  of  axiom  addition 
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(A5)  Use  Algorithm  X  to  expand  rows  until  S^Z  is  a  row. 

Because  Algorithm  X  is  not  as  "smart''  as  it  could 
be  the  result  is  a  larger  table  than  necessary. 
This  will  be  corrected  at  the  end  by  contraction. 
Altogether,  Algorithm  X  is  invoked  three  times. 


Figure  8-9  (Part  2  of  9).  Example  of  axiom  addition 


4 

(A6)  Remove  S  Z  from  :  Use  Algorithm  R 

(Rl)  k  -  4 

(R3.1)  dom(W)  ■  form(Z) 

(R4.1.1)  R'  -  S4Z  ,  X  -  Z 

(a)  Remove  Z  from  dom(Z) 

4 

(b)  Remove  S  Z  from  table 


T1 

V1 

-J 

p 

z 

V1 

PZ 

PV1 

V1 

P2vl 

sz 

V1 

PSZ 

SPV1 

vi 

PSPVL 

s2z 

V1 

PS2Z 

S2PV1 

V1 

PS2PV1 

s3z 

V1 

PS3Z 

3 

S  PVj 

V1 

PS3PV1 

S4PVX 

V1 

4 

PS  PVj 

s5z 

V1 

PS5Z 

S5PV1 

V1 

PS5PV1 

s6z 

VI 

PS6Z 

S6PV1 

V1 

PS6PV1 

s7z 

V1 

PS7Z 

S7PV1 

V1 

PS7PV1 

s8v 

V, 

PS8V 

1 

1 

1 

S 

SZ 

SPV 

S2Z 


1 


s2pv 

S3Z 

s3pv 

S4Z 

4 

S  PV 
S5PV 
S6Z 
S6PV 

s7z 

S7PV 

S8Z 

s8pv 

sY 


1 

1 

1 

1 

1 

1 

1 


Figure  8-9  (Part  3  of  9).  Example  of  axiom  addition 
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(R4. 1.2) 

Remove 

S5Z  . 

(  8l  ■  S 

) 

(R4. 1.3) 

Remove 

s6z  . 

(  8^2  - 

s2  ) 

(R4 . 1.4) 

Remove 

s7z  . 

(  8 1 8  2  8  3 

-  s3  ) 

Figure  8-9  (Parc  4  of  9).  Example  of  axiom  addition 


4 


(R4.1.5)  R 1  -  S8V1  (  g1g2g3g4 
(a)  Replace  V1  with  V2: 

dom(V2)  ■  dom(V^)  - 


T, 

1  V1  1 

1  V2 

P 

s 

z 

V1 

- 

PZ 

— 

sz 

PV1 

V1 

V2 

2 

pzv: 

SPVX 

sz 

V1 

V2 

PSZ 

s2z 

SPV1 

V1 

V2 

PSPV1 

S2PV1 

s2z 

V1 

V2 

2 

PS  z 

S3Z 

S2PV1 

V1 

V2 

ps2pv1 

S3PV1 

s3z 

V1 

V2 

3 

PS  Z 

s4z 

S3PV1 

V1 

V2 

ps3pv1 

4 

s  PV; 

S4PVl 

V1 

V2 

ps4pv1 

S5PV1 

S5PV1 

V1 

V2 

PS5PV1 

S6PV1 

S6PV1 

V1 

V2 

PS6PVl 

S7PVl 

S7PV1 

V1 

V2 

ps7pv1 

S8PV1 

S8v2 

V1 

V2 

PS8V2 

s9v2 

( R  5 .  1 )  k  -  3 

( R 3 . 2 )  dom(W)  -  form(SZ) 


-  S4  ),  X  -  V 
f  o  rm  (  Z ) 


Figure  8-9  (Part  5  of  9).  Example  of  axiom  addition 
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U4'2)  r.'sC'2  <gi-'-84  ■  s‘  ■  f‘f2f3  ■ s3  * 

(a)  Replace  with  :  remove  form(SZ) 


(R5.2)  k  -  2 

(R3.3)  dom(W)  -  form(S2Z) 

(R4 . 3 )  Replace  V3  with  V4  :  remove  form(S2Z) 
(R5.3)  k  -  1 

(R3.4)  dom(W)  -  form(S3Z) 

Figure  8-9  (Part  6  of  9).  Example  of  axiom  addition 
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(R4.4)  Replace  with  Vj  :  remove  form(S3Z) 


T1 

V1 

V5 

P 

s 

z 

V1 

PZ 

sz 

PV1 

V1 

V5 

p2yi 

SPV1 

sz 

V1 

PSZ 

s2z 

SPV1 

V1 

V5 

PSPV, 

S2PVX 

2 

S  Z 

V1 

2 

PS^Z 

3 

s  Jz 

2 

S  PV 

V1 

V5 

PS2PV1 

3 

S  PV 

3 

S  Z 

V1 

PS3Z 

S*2 

3 

S  PVj 

V1 

V5 

PS3PV1 

S4PV1 

4 

S  PV{ 

V1 

V5 

PS4PV1 

S5PV1 

S5PV1 

V1 

V5 

PS5PV1 

S6PV1 

S6PV1 

V1 

V5 

6 

PS  PVj 

S7PV1 

S7PVX 

V1 

V5 

PS7PV1 

S8PV. 

S8V5 

V1 

V5 

PS8V5 

s9v5 

(R5.4)  k  -  0 

(R2.5)  Quit  Algorithm  R 


Figure  8-9  (Part  7  of  9).  Example  of  axiom  addition 


S3Z  ,  S  ) 


( A  7 )  Substitute  Z  for  S4Z  in  E( 


T1 

V1 

V5  1 

P 

s 

» • 

- — - 

z 

V1 

PZ 

sz 

PV1 

V1 

V5 

P2Vi 

SPV1 

sz 

V1 

PSZ 

s2z 

SPV 

V1 

V  5 

PSPV1 

S2PV1 

V1 

2 

PS  Z 

3 

SJZ 

2 

S  PV1 

V1 

V5 

PS2PV1 

S3PV1 

3 

S  Z 

V1 

3 

PS  Z 

z 

s3pv1 

V1 

V5 

ps3pv1 

S4PV1 

S4PV1 

V1 

V5 

PS4PV1 

S5PV1 

S5PV1 

V1 

V5 

PS5PV1 

S6PV1 

S6PV1 

V1 

V5 

PS6PV1 

S7PV1 

S7PV1 

V1 

V5 

PS7PV1 

S8PV1 

s8v5 

V1 

V5 

PS8V5 

s\ 

(A8)  Use  Algorithm  K  with  0  ■  ^S4Z  -->  Z~\ 
No  new  rewrite  rules  generated. 


(A3)  Quit  Algorithm  A 


Figure  8-9  (Part  8  of  9).  Example  of  axiom  addition 
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Using  Algorithm  C,  rows  SPV1  ,  S2PV1  ,  S3PV1  ,  ...  , 
7  8 

S  PVL  and  S  can  be  contracted  into  SV^  : 


T1 

V1 

V5 

P 

s 

z 

V1 

PZ 

sz 

PV! 

V1 

V5 

p2Vi 

SPV1 

sz 

V1 

PSZ 

s2z 

S2Z 

V1 

2 

PS^Z 

s3z 

s3z 

V1 

3 

PS  JZ 

z 

SV5 

V1 

V5 

PSV5 

2 

S  v5 

Figure  8-9  (Part  9  of  9).  Example  of  axiom  addition 


9.  Implementations  and  Tables 

Table  specifications  correspond  nicely  with 
implementations  in  two  ways:  (1)  The  partitioning  of  a  type 
into  table  rows  is  often  mirrored  by  the  partitioning  of  a 
function's  input  into  disjoint  cases,  treated  by  disjoint 
control  paths.  (2)  The  existence  of  a  table  specification 
ensures  the  existence  of  an  implementation — the 
implementation  of  tablalg  . 
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9.1.  Program  Partitions 


From  the  control  structure  statements  of  a  function  in 
a  class,  a  set  of  control  paths  may  be  determined. 


DEFINITION  9.1  -  Let  f:  T,  x  ...  x  T  - >  T  be 

-  i  n 

a  function  in  a  class.  Let  t^  ,  ...  ,  tQ  be 

constants  of  types  T^  ,  ...  ,  Tn  . 

Path( f  ,  ( t  ,  ...  ,  tn))  is  the  sequence  of 

non-control  statements  executed  by  f  on  input 


Because  we  have  assumed  totality  of  all  class  functions, 
pathCf.Ctj  ,  ...  ,  tn))  is  always  a  finite  sequence  of 

statements.  Because  no  side  effects  are  allowed,  execution 
of  control  statements  does  not  change  the  values  of  any 
variables . 


DEFINITION  9.2  -  Let  f:  T,  x  ...  x  T  - >  T  be 

-  1  n 

a  function  in  a  class.  Let  t.  ,  ...  ,  t  be 

1  n 

constants  of  types  T^  ,  ...  ,  Tn  . 

Func ( f , ( t i  ,  ...  ,  tn))  is  the  constant  function 

defined  by  execution  of  the  sequence  of  statements 
path(f,(t1  ,  ...  ,  tn) )  .  *** 

An  Implementation  of  func(f,(t^  ,  ...  ,  tfl))  is  easily 

constructed  by  generating  assignments  of  the  values  of 
tj  ,  ...  ,  tn  to  the  parameters  of  f  and  generating  the 
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sequence  of  statements  in  P  .  The  values  of 
tj  ,  ...  ,  t  must  be  expressed  in  terms  of  the  primitive 

types  of  the  language.  For  example 
f unc ( Push ,( Ze ro , News  tack )  )  (see  Figure  5-2)  is  the 
sequence 

Resul t . Va 1 s ( 0 )  :»  0 

Result. Tops  :■  0  +  1  . 

Such  functions  are  not  very  interesting  by  themselves,  but 
combine  with  each  other  in  a  nice  way. 
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DEFINITION  9.3  -  Let  f:  T,  x  ...  x  T  - >  T 

and  g:  T^'  x  ...  x  Tn'  --->  T  be  functions  with 
disjoint  domain  arities: 

T  ^  A  Ti'  -  0  i  »  1  ,  .  .  .  ,n. 

The  s urn  of  f  and  g  is  a  function  with  meaning: 

If  +  g]:  (T  x  x...x  Tq)  +  ( T  x  '  x...x  T^) - >  T, 

where  T  +  T'  denotes  the  disjoint  union  of  types 
T  and  T '  ,  such  that 

[f  +  g  ]  ( t  ^  ,  ...  ,  tn)  -  f(t^ . t  )  when 

tt  €  Tx>  i  »  I  ,  .  .  .  ,  n 

[f  +  g  ]  ( t  x  ,  ...  ,  tn)  -  g(tj . tn)  when 

t^  4  ^ '  i  -  I  ,  . .  .  ,  n  . 

We  denote  the  meaning  of  the  sum  of  all  functions 

f^:  T ^  x  ...  x  T^  - >  T  ,  i  6  I  ,  an  index 

1  n 

set,  by 


*  *  * 
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PROP F  -  The  set  of  functions  in  the  sum  is  the  set 
of  all  constant  functions  generated  by  considering 


every  constant  word 

in  form(fVj. 

c 

> 

• 

• 

,  where 

V  ^  has 

domain 

T  . 
i 

•  The  set  of 

constants  is 

disjoint, 

so  the 

sum 

is  defined. 

The 

set  of 

constants 

covers 

all 

values  of  f 

,  so 

t  he 

equality 

ho  Id  s . 

*  *  * 

9.2.  Table  Partitions 


Very  few  useful  functions  are  written  as  giant 
case-s tatement s ,  with  each  case  a  constant  function.  So, 
very  few  useful  functions  are  syntactically  divided  by  the 
set  of  all  func(  )  functions.  On  the  other  hand,  very  few 
functions  are  written  with  straight-line  code,  with  no 
control  statements.  A  good  programmer  strikes  a  balance 
between  these  extremes.  Table  specifications  help  define 
such  a  balance. 

We  extend  the  definition  of  the  path  function  to  sets 
of  input  values. 


DEFINITION 

9.5  - 

Let 

ft  T|  x  «  *  • 

x  T  - >  T 

n 

be 

a  function 

in  a 

class  . 

Let  R  - 

£ R ^  be  a 

set 

of  constants  in 

T1  x 

.  .  .  x  Tn  . 

Path( f , R ) 

is 

the  set  of  sequences  £path( f  ,  .  *** 

We  intend  to  use  rows  of  tables  for  the  sets  R  .  Since  the 
rows  of  a  table  are  disjoint,  it  is  natural  to  expect  the 
paths  of  rows  to  be  disjoint. 


L 
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DEFINITION  9.6  -  Let  f  be  a  function  in  a  class 
of  domain  arity  T  .  Let  Rj  and  R2  be  subsets 
of  domain  T  .  R^  and  R2  are  f-independent  if 
and  only  if 

path(f,R1)  A  path(f,R2)  -  0  . 

Rj  and  R2  are  independent  if  and  only  if  they 
are  f-independent  for  all  functions  f  of  domain 
arity  T  in  the  class.  *** 


The  rows  <Newstack>  and  <PushXNXS>  in  the  table 
specification  of  Stack  (see  Figure  7-5)  are  independent  in 
the  Implementation  in  Figure  5-2.  The  sets  |<Zero>]  and 
^<SuccXZero>^  are  not  independent  in  the  implementation 
in  Figure  5-1. 


The  degree  to  which  the  control  structure  of  a  function 
f  in  a  class  corresponds  to  the  row  structure  of  the 
corresponding  table  in  a  table  specification  is  measured  by 
the  f-independence  of  the  rows  in  the  table. 
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9.3.  Relative  Correctness 

The  division  of  a  function  by  rows,  or  sums  of  rows, 
leads  to  a  division  of  its  correctness.  Since  a  function  is 
determined  by  the  sum  of  its  components,  its  correctness  is 
similarly  divisible. 

DEFINITION  9.7  -  let  f:  T,  x  ...  x  T  - >  T  be 

-  1  n 

a  class  function.  Let 

F:  T'  x  ...  x  T  '  - >  T*  be  a  function  in  a 

1  n 

data  abstraction.  Correc  t ( f ,  F)  »  True  if 
there  exists  an  epimorphism 
h:  (T{  x  ...  x  Tn)  >  (Tj'  x  ...  x  Tn')  , 
h:  T - >  T  '  ,  such  that 

h(f(t|  ,  • • •  ,  t  n ) )  *  F(h(t|  ,  • • •  9  t  n ) )  • 

*  ★  * 

This  definition  merely  adds  notation  to  the  notion  of 
correctness  defined  in  chapter  5. 
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THEOREM  9.8  -  Let  f  be  a  class  function  of  domain 
arity  T  .  Let  F  be  a  function  in  a  data 
abstraction  of  domain  arity  T'  .  Let  and 

R2  be  f -independent  sets  of  domain  T  . 
Correctness  of  f  with  respect  to  F  over  the 
disjoint  union  of  R^  and  R2  may  be  factored 
into  its  correctness  over  each: 
correct( func( f  ,  R^ )  + 

f  unc ( f ,R2) ,F) 

if  and  only  if 

correct(func<f  ,R1 )  ,F)  AND 
correct ( f unc ( f ,R2 ), F)  .  *** 


PROP F  -  Since  R^  and  R2  are  f-independent ,  we 
may  construct  functions  f^  and  f2  ,  such  that 
(fl  “  [fj  +  f2l 
and 

f(Rl)  -  .  f<R2>  “  f2(R2)  • 

Suppose  fj  and  f2  are  both  correct. 

Then,  there  exist  epimorphisms  hj  »  h ,  ,  such 

that 

h1(f1(Ri))  -  F(hi(Ri)  )  i  -  1  ,2  . 

But,  that  means  there  exists  an  eplmorphism 
h  •  hj  +  h2  . 


So  f  is  correct. 
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Conversely,  let  f  be  correct.  Then  there 
exists  an  epimorphism  h  ,  such  that 

h ( f ( t ) )  -  F ( h ( t )  )  ,  for  all  t  4  T  . 

But,  the  division  of  T  into  f-independent  sets 


and 

yields 

h(  f  ( t  j,  ) ) 

-  F(h(tj)) 

,  for 

all 

li  4  Ri  • 

h(f (t2)) 

-  F(h(t2)) 

,  for 

all 

t2  €  r2  • 

But , 

f(ti)  -  f1(t1)  ,  i-1,2. 

So , 

h(f1(t1))  -  F(h(t1))  .  i-1,2. 

Therefore,  f^  and  f 2  are  correct.  *** 

The  significance  of  the  theorem  is  that  Identification  of 
f-independent  sets  allows  decomposition  of  correctness 
proofs  by  control  paths.  When  the  sets  are  rows,  this  means 
that  a  function  can  be  proved  correct,  row-by-row. 
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10.  Summary 


Correctness  is  a  relationship  between  a  real  object,  a 
specification  or  a  class,  and  an  abstract  object,  an 
intended  data  abstraction.  The  correctness  of  two  real 
objects,  a  specification  and  a  class,  with  respect  to  the 
same  abstract  object  yields  a  relationship  between  the  two 
real  objects.  We  have  shown  that  this  relationship  may  be 
described  by  a  lattice. 

Each  element  of  the  lattice  has  a  structure — congruence 
classes.  These  are  used  in  table  specifications.  Each  row 
in  a  table  describes  a  collection,  or  pattern  of  congruence 
classes.  The  partitioning  of  congruences  into  patterns  of 
congruence  classes  is  often  mirrored  by  the  partitioning  of 
implementations  into  control  paths.  This  is  useful  in 
software  maintenance. 

Axiomatic  specifications  are  useful  in  design  of  data 
abstractions,  but  they  are  awkward  to  use  in  software 
maintenance  for  two  reasons:  (1)  The  effect  of  a  change  is 
determined  by  the  total  context  of  the  specification.  That 
is,  all  axioms  must  be  considered  in  making  any  change.  (2) 
The  syntax  of  a  change  to  a  specification  provides  little 
assistance  in  making  a  corresponding  change  to  an 


im  pi eme  nt a  1 1  on 
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The  first  problem  is  familiar  to  programmers  who  write 
highly-dependent  code:  each  statement  in  a  program  affects 
and  is  affected  by  practically  every  other  statement.  A 
one-line  change  to  such  a  program  may  have  quite 
unpredictable  results.  Structured  programming  is  an  attempt 
to  avoid  such  problems  by  separation  of  concerns.  Table 
specifications  are  an  example  of  "structured  specification,” 
where  the  rows  of  the  tables  are  the  concerns  separated. 

The  second  problem  with  axiomatic  specifications  is 
caused  by  the  first.  Since  most  programmers  (we  hope)  use 
structured  programming  techniques  in  implementing  data 
abstractions,  changes  may  be  localized.  Changes  to 
specifications  should  also  be  localized,  and  in  the  same 
way. 
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